Date: Wed, 7 Jan 1998 05:15:58 -0600 (CST) From: "Daniel M. Eischen" <deischen@iworks.InterWorks.org> To: aic7xxx@freebsd.org, mikebw@bilow.bilow.uu.ids.net Subject: Re: Tagged Queueing and Dque Bit Message-ID: <199801071115.FAA24491@iworks.InterWorks.org>
next in thread | raw e-mail | index | archive | help
> 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@iworks.InterWorks.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801071115.FAA24491>