Re: Just a couple of things

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

========================================================================
1. some easy (quick) way to detect a running ACSI/SCSI/IDE transfer,
at least those that go to sleep...  so have all drivers set some common
flag, maybe different bits for each port?  IO_SINGLE then can be &flag
========================================================================

The easiest common flag would be to use flock @ 0x0043e since this 
location is already set aside as a semaphore for accessing DMA registers.
This should give MiNT some extra compatibility, in case something access
the DMA without going through MiNT - it =SHOULD= check here.

When set, MiNT should put the process to sleep, otherwise start-up a DMA
transfer for the driver.  When the interrupt goes off, remove the waiting
process from its queue and clear "flock".  Then check and see if another
process was put to sleep during the transfer and should take care of it.
I'm assuming that only parts of MiNT would be semaphore locked during
the transfer, and that you could still use fread/fwrite for console
IO and such, right?

========================================================================
2. some good way to check for `systemcall came from inside GEM', any
ideas? :)  ditto for how to hook into trap #2, i once read GEM likes to
throw you out there...
========================================================================

Hmm .. well, we don't need this if it was the ROM AES that started the
transfer, since it will be the AES process that gets put to sleep, not
the user app, well, the user's app will too since its waiting on the AES.
So we don't need to lock that. 

Here is a quick hack that will work.  Look at the return address.  It gets
put on some stack somewhere.  If the return address points into ROM (either
of the ROM locations, anything from 0x00e00000 - 0x00ffffffff or the
same with the high byte 0xff since that area shadows the others.  So, if
the call is from the ROM, then we can set a flag of some sort.  This
also blocks the ROM desktop calls, in addition to VDI/AES, but I can't
think of any other way.

========================================================================
3. are there already devices (/dev) that call disk drivers and so would
go to sleep too?  they might need changes too.  or should devices also
get a `multithreaded' bit...
========================================================================

No, I don't think so.  Hmm .. nope.

========================================================================
4. anything else i forgot?
========================================================================

I don't know.  Are you forgetting anything?