I wrote:

	 > >I've wondered if it would be easier to write a real driver that
	 > >depends on a user process for context (ie; a process which does an
	 > >ioctl() which never returns) for the scsi I/O.

Then Marc Boschma <marcb@bms.itg.telstra.com.au> wrote:

	 > Phil, could you expand on this, as I think I'm missing the
	 > whole thrust of this thought...

Finally, Jason Wrote:

	...except you don't _need_ process context... i.e. network
	drivers don't currently run in process context, and the SCSI
	code doesn't have to, either.

	Can you explain why you think you need to have a process there?

Well, since you asked....

It's my opinion as an admittedly stodgy and conservative engineer,
(but one who has shipped many solid releases, on time) that while it
may be possible to coax async I/O out of the NetBSD SCSI I/O system,
(set this flag here, that flag there, allocate your own buffers, make
sure noone else frees them...) it will end up being fragile.  It
doesn't look like anyone else does it, even if you get it working,
keeping it that way may be hard.

Much better to pick a strategy that will keep working, and do the I/O
from a process context, where you can, for example request regular I/O
buffers and not worry if you have to sleep.  Of course I'm assuming
the whole buffered I/O doesn't mutate (ie; into an integrated I/O VM
system) like the infamous bug-blatta beast of traal.

I know this isn't the NetBSD way, to settle for something easy to
implement that will work solidly, but then I believe better is the
enemy of good.