Re: GEMDOS re-entrancy

[Ulrich Kuehn <kuehn@GOEDEL.UNI-MUENSTER.DE>]

Hello!

|>1) GEMDOS must be re-entrant.  It isn't.
|>
To make it clear: meant is the GEMDOS in the ROM, which is used by MiNT
as filesystem and as provider for some other I/O services, right?

|>2) Process B must not make a GEMDOS call.  This could lead to some weird
|>   multitasking.  I guess it would work, but halting the AES when a program
|>   tries to load fonts could get kinda hairy.  Processes that can't call
|>   GEMDOS cannot accept input or display output.  This will work, but it's
|>   hairy.
|>
The AES does not make direct jumps into the GEMDOS in ROM, it goes via
trap vector, so it will first run through the MiNT kernel. But for disk
accesses, it will be blocked anyway, as there is no way to run two trans-
fers simultaniously :)
But all the other MiNT services which do not rely on the old GEMDOS are
not affected.

|>3) Make process A sleep OUTSIDE GEMDOS.  There must be some way to clean up
|>   GEMDOS while process A sleeps, perhaps exiting GEMDOS and putting the
|>   process on some sort of wait queue.  Then have the process re-enter
|>   GEMDOS when the IO is complete.  There has GOT to be some way to clean
|>   things up.
|>
|>I'd rather make GEMDOS re-entrant, but failing that perhaps option 3 could
|>be implemented?
|>
Sounds sort of difficult. Do you have the complete source of Gemdos? A
better choice would be to have a tos xfs, then we get rid of a whole
pile of problems at once. May be the linux sources can be modified
easily?

Regards,
Ulrich