Tagged Queueing and Dque Bit

[Daniel M. Eischen]

>  DME> Ahh, but we're not in a good position to do this.  And when you 
>  DME> think about how this affects other drivers you'll see why it is 
>  DME> better in the mid-level SCSI code anyways - why have duplicate 
>  DME> code in each driver doing exactly the same thing?
>
> I see your point, but the definition of the bit in the Scsi_Device structure is
> at issue: it could mean "If drivers want do tagged queueing then we don't have
> any problem with that up here," or it could mean "It is safe for drivers to do
> tagged queueing."  These are very different things.

There are two bits in the Scsi_Device structure.  One that says the
device is capable of tagged queueing and one that says tagged queueing
is currently enabled.  There is even a tag count placeholder in the
Scsi_Device structure that the driver can use for keeping track of
an incrementing tag value.  The mid-level SCSI code sets the bit
that says "this device can do tagged queueing".  The driver then
sets the bit that says "we are now doing tagged queueing on this
device" when the driver starts performing tagged queueing for the
device.

But the real point I was making is that the driver is not in
a good position to detect the setting in the mode page.  It
does not generate Scsi_Cmnds, queue them to the device,
control the timeout for the command, and handle errors
when they occur (of course some error processing is done
in the driver for things that have to be there, but the
core-logic for deciding how and when to resend/abort commands
is in the mid-level SCSI code).  The driver also has no 
concept of when devices are being probed.  That also is in
the mid-level SCSI code during scan_scsis() in scsi.c.

THe mode page is never read by the mid-level SCSI code,
so we can't peek into it either.  If it were to be read,
then it should be in the mid-level SCSI code at device
probe time when the device was detected as tagged
queueing capable.  It would be much easier (and better)
to do it there.  It would be a mess trying to do it in
the driver, also cluttering up what is already a complicated
driver, IMHO.

Regards,

Dan Eischen
deischen at iworks.InterWorks.org