Subject: Behavior of I/O polled cmds
To: None <tech-kern@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: tech-kern
Date: 08/05/1998 18:41:34
Hi,

I've been doing a lot of work on the IDE driver in the last days (not
yet commited :) and while implementing polled I/O for IDE and ATAPI
I ran into a problem:
The commands are queued at the controller level, so when a cmd comes
you can have a command in the queue. In this case, the polled command will
be delayed wich will break kernel core dumps.
So what's the exact required behavior for SCSI polled cmds ?
When a polled cmd comes in, the current xfer needs to be aborted.
Should the command queue be restarted after a polled command ?
The queue needs to be frozen while the dump is being written, but
then we need something to say "freeze the queue" and "restart the queue". Also,
just discarding the queue at the first polled cmd makes the driver much much
simpler.
But restarting the queue may have an interesting feature: getting a kernel
core dump and continue execution.
I'm not sure it's worth the effort.

Opinions ?

--
Manuel Bouyer, LIP6, Universite Paris VI.               Manuel.Bouyer@lip6.fr
--