Tagged Queueing and Dque Bit

[Mike Bilow]

Daniel M. Eischen wrote in a message to Mike Bilow:

> If the mid-level SCSI code is depending solely upon the INQUIRY 
> response without either reading or writing the Control Mode 
> Page, then this is a clear error that needs to be fixed -- it 
> may solve a lot of problems.

 DME> I don't have the Linux mid-level SCSI code handy, but it is
 DME> indeed checking the INQUIRY response and setting the tagged
 DME> queueing bit in the Scsi_Device structure.  This bit in the
 DME> device structure, along with driver configuration options,
 DME> are the only things that the driver looks at in determining
 DME> whether to perform tagged queueing or not.  Whoever sets
 DME> this bit (the Linux mid-level SCSI code) should be the
 DME> responsible party.  Furthermore, SCSI commands should come
 DME> from the Linux mid-level SCSI code and not from the driver
 DME> (with the exception of the sense request).

I agree that the mid-level SCSI code is responsible, and the behavior you
describe is wrong: the DQue bit on the Control Mode Page should be either read
or written before tagged queueing is enabled.  To some extent, the state of the
DQue bit is a user responsibility outside the responsibility of the code,
something like termination, but I think it is good practice to at least warn of
any inconsistencies we detect.

Technically, my understanding was that the Scsi_Device structure bit was to be
interpreted by the driver as necessary but not sufficient.  One could even take
it as a mere suggestion, since the driver is not even obliged to support tagged
queueing.  It might be worth clarifying exactly what the bit is supposed to
mean, since it is obviously critical that the mid-level SCSI code and all
drivers should interpret it in the same way.

That said, it would certainly be a good idea for the mid-level SCSI code to
read or write the DQue bit before setting the bit in the Scsi_Device structure.

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