Re: Just a couple of things.

[Juergen Lock <nox@jelal.north.de>]

Claus Brod writes:

> > then you can still type in windows etc. when processes do normal disk IO
> > not thru GEM calls.  (hmm or does the blitter confuse DMA?)
> 
> Well, it's the other way round - for IDE transfers, the blitter
> is used, so noone else may use it.

 oops forgot about those...

>  Uh, oh, I didn't think about
> that one yet. (Probably because my driver doesn't support IDE
> drives yet. 8-) Help, we need a blitter semaphore!
> 
> Hmmm, on a normal ST/STE I could just "turn off" the blitter for
> the OS so that noone can use it while disk transfers are going
> on. On the Falcon, however, the blitter cannot be turned off -
> without NVDI, that is.

 well then you have it like on PCs, only SCSI disks get DMA, IDEs are
polled and the CPU moves all the data itself.  maybe you can nap() until
the first byte is ready... :)
> 
> >  thats the idea, now what did i miss? :)  cheers
> 
> You forgot to implement it and send it around as a patch 8-)

 not so fast :)  first, what do we need...

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
i.e. wake (IO_Q, &flag) when you return to caller.  (or should the
kernel do this itself for the `old-style' BIOS drivers?  but since they
need kernel calls for sleep etc. anyway...)

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...

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...

4. anything else i forgot?

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA