Re: [Freemint-discuss] O_GLOBAL issues

[Miro K. <mir...@gm...>]

>
> I can see the implementation of O_GLOBAL but I'm not 100% confident of its
> purpose. To me it looks like a way to ensure that whatever file is opened
> (even created in the past), it should be always handled as a file belonging
> to the root process ("MiNT") and not others (AESSYS, NEWDESK, SCREEN etc).
> That seems to have some unique properties like ensuring that no key is lost
> due to task switching (or so, happy to be corrected here). The way it was
> implemented was quite weird, basically any process handle >= 100 was
> considered global, essentially limiting the number of open (non-global)
> file handles to 99.
>
I have spent some time looking into this and now I get it (I think). The
idea behind O_GLOBAL is that one process (e.g. the root one) can
open/create a file (identified by a file handle) and other processes
(NEWDESK, AESYSS, ...) can read/write from/to it. You might think "huh? but
why not just pass them the same file handle upon opening?" and that's the
issue here: in a multitasking OS, file handles are a process property. So
file handle = 6 is a different file for "MiNT", different file for "AESSYS"
etc.

In a nutshell:

   - "MiNT" (the kernel) opens /dev/console for read/write
   - "AESSYS" opens /dev/console for read/write with O_GLOBAL and gets a
   file handle
   - ("AESSYS" somehow distributes returned file handle to everyone
   interested, perhaps as "this is the console device")
   - Everyone can now read and write from/to /dev/console as if they were
   all root processes

As this has been deprecated, I'm wondering: couldn't we just make one flag
> in console.c (or dosfile.c) which would tell "this file handle is
>
global because it belongs to /dev/console" and treat it always as root
> process handle?
>
Now we see that this is not possible: we can't compare file handles and
even process IDs: any process is allowed to access the "root file handle"
and yet any process can have the same file handle (e.g. 6) used for
completely different purposes! So the only way to differentiate between
those two is to add some kind of flag to the returned file handle value.
Original MiNT authors decided to use +100 but OR'ing e.g. 0x8000 to the
resulting file handle would work perfectly well, too.

So this is the reason why Helmut's workaround works only partially: it just
pretends that O_GLOBAL doesn't exist. So sometimes it reads from the
correct file handle (AESSYS is reading from regular /dev/console),
sometimes reading fails (e.g. NEWDESK is instructed to open file handle = 6
for accessing /dev/console and it fails because it doesn't have such a file
handle assigned) and sometimes it reads garbage (because file handle = 6 is
e.g. c:\cops.inf and not /dev/console...).

So what can be done about it?

   1. Reverting back to the original O_GLOBAL code for /dev/console but
   using a much bigger offset (e.g. 0x8000, i.e. max 32k opened files)
   2. Making sure that the file handle assigned to "AESSYS" is never used
   in another process, i.e. making the comparison in the way I'm proposing
   above
   3. ???

Having in mind that removal of O_GLOBAL led  to lifting the max file
handles limit from 32 to 1024, I don't have any bad feelings about doing
the first proposal with 0x8000. It's tested and easy to understand but
maybe the second one is a bit cleaner. I don't know.

Oh and since we need this workaround in any case (to make N.AES, AES 4.1
and maybe others happy), we can apply a similar exception to the other bad
boy in town: slip.xif.

-- 
http://mikro.atari.org