Re: Just a couple of things.

[Erling Henanger <erlingh@idt.unit.no>]

> 
> In <9404271422.AA20250@hpbeo79.bbn.hp.com> you wrote :
> 
> >> Well, at least with source code to the CBHD driver, we would be able
> >> to make such a driver. Making the driver respond to interrupts instead
> >> of polling can't be that big a problem. At least not when all the
> >> scsi setup code can be ripped off this driver. How much work it will
> >> be to setup the queues of processes wanting to do IO under MiNT 
> >> I won't comment on.
> >
> >It's certainly not trivial to get all debugged, but it's not the
> >biggest issue. We need kernel reentrancy first, that's the main
> >problem.
> 
> Bingo!
> 
> While we are talking about all this, and people are writing lots of code
> to talk to the SCSI port(s)...

Exactly, this was one of the things I thought about.
Just take this guy using a CD-rom. He will probably have:

	a) AHDI:		 To control his hard-disks
	b) MetaDOS or some .xfs: To control his CD-roms
	c) Some kind of CD-audio player.

Now all of these programs/drivers contains code that are talking to
the SCSI ports. And they might even be talking in each others mouth.
Take AHDI for instance, it never *checks* the DMA-controller 
semaphore - it just sets it and then goes on doing its thing.
If,say, the audio-player was in the middle of performing some
scsi-command when AHDI decided to do its thing, wild things could happen !

Some kind of /dev/scsi device that could actually send the commands
for all of these programs would be very nice. Then, when the time
comes and mint is reentrant, one would only have to rewrite the
/dev/scsi driver to be interrupt driven, and all the high level
stuff would instantly take advantage of it.

> 
> Can we _please_ have a low-level SCSI driver that knows _nothing_ about 
> filesystems or disks or anything like that?

Me too.

Erling