GEMDOS re-entrancy

[ekl@sdf.lonestar.org (Evan K. Langlois)]

========================================================================
 (hmm i didn't that one..)  on MiNT console IO has nothing to with GEMDOS,
for MiNT GEMDOS is just a bugged messdos-filesystem with clock. :)
========================================================================

I was under the impression that parts of MiNT were not re-entrant.  If you
can open files and such on a Minix drive (without calling the ROM GEMDOS)
and all the functions to do so are re-entrant, then why block GEMDOS when
you could just make a real TOSFS that doesn't call the ROM.

Otherwise, what parts of MiNT aren't re-entrant?  Time functions could be
allowed to block, as most other things, as long as disk IO doesn't lock the
whole system.  As for DMA hard disk IO having problems with the BLiTTER,
isn't there a semaphore for this?  Yeah, here it is, flock @ 0x0000043E.W

Hmm .. if rwabs were to be replaced by a call that puts the call on a wait
queue, and then waits for an interrupt (and maybe a timeout??) what interrupt
would it wait for?  What is the DMA "complete" interrupt?  I would guess
that any "SCSI driver" would replace rwabs and install into  ... I guess
all the hdv_ vectors located between 0x046a and 0x047e?  I guess the DMA
interrupt for ST/STe/Falcon machines is MFP #5, and on the TT SCSI is 
TT-MFP #5 & #7?

A real hard disk driver is beginning to sound like a more complex version
of /dev/lp or the modem devices, but it would follow the same principles
right? 

I just wanna make sure I'm thinking along the same lines as everyone else
though.  What are the XHDI (or whatever its called) functions?  I'd like
to be able to bypass my current driver completely (AHDI) since its so
damn slow to start-up (and my AdSpeed makes it try and detect IDE drives
using my BLiTTER - a useless waste of time on an STe).  I would guess we'd
need a boot-strap program of some sort though to get a hard disk driver
before MiNT loads (and it would be nice to get rid of my last FAT partition).

Hmm .. as for locking the AES and VDI when they make a call that would
normally block the system .. how about we see if it needs it first.  There
is a good chance that locking GEMDOS will be sufficient, and having another
application open a window or something like that before the AES is done
loading fonts for another app, just might not cause any weird effects. There
is always wishful thinking.  Or, there is a real easy and compatible method
in this situation .. when the AES or VDI makes a GEMDOS call, lock the
whole system up again :-)   Atari should give us the source code to AES and
VDI so we can see what exactly is re-entrant and what isn't :-)

Hmm .. how many DMA channels does the STe have?  There is DMA sound,
DMA hard disk, and DMA BLiTTER ... and on a Falcon aren't the SCC ports
DMA??  I know the Falcon has separate channels for sound.  Are the STe's
sound DMA channels separate from others?  What about floppy access?  IS
that doomed to lock up the system?