--- On Tue, 2/5/08, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > > --- On Tue, 2/5/08, FUJITA Tomonori > <tomof@xxxxxxx> wrote: > > > On Mon, 4 Feb 2008 18:39:22 -0800 (PST) > > > Luben Tuikov <ltuikov@xxxxxxxxx> wrote: > > > > > > > --- On Mon, 2/4/08, Boaz Harrosh > > > <bharrosh@xxxxxxxxxxx> wrote: > > > > > There are 3 usages of sense handling in > drivers > > > > > > > > > > 1. sense is available in driver > internal > > > structure and is > > > > > mem-copied to upper level > > > > > 2. A CHECK_CONDITION status was > returned and the > > > driver > > > > > uses the scsi_eh_prep_cmnd() > > > > > for a REQUEST_SENSE invocation to > the target. > > > Then > > > > > returning the sense in > > > > > scsi_eh_return_cmnd(). A variation > on this is > > > when the > > > > > driver does nothing the queue > > > > > is frozen an the scsi watchdog timer > does the > > > above. > > > > > 3. The underline host adapter does the > > > REQUEST_SENSE and a > > > > > pre-allocated and DMA mapped > > > > > sense buffer receives the sense > information > > > from HW. > > > > > > > > Many years ago when "ACA" had a > constructive > > > meaning, > > > > so did "Autosense". Then about 5 > years ago, > > > "Autosense" > > > > disappeared completely since it became the > de facto > > > > implementation of the then SCSI Execute > Command > > > "RPC", > > > > now just SCSI Execute Command procedure > call. > > > > > > > > At that point in time, the SCSI mid-layer > decided > > > > to embrace this model and give the LLDD a > scsi command > > > > structure which included the sense data > buffer to > > > > a size that the SCSI mid-layer was > interested in, > > > > at the moment 96 bytes, macro defined in > > > > include/scsi/scsi_cmnd.h. > > > > > > > > The concept of "Autosense" was > off-loaded to > > > LLDD > > > > to emulate it if the specific target device > to > > > > which the command was issued, didn't > supply the > > > > sense data on CHECK CONDITION, and more so > > > > relevant to target devices which implemented > > > > queuing, thus the ACA. > > > > > > > > And the mid-layer would consider extracting > > > > the sense data via REQUEST SENSE command > > > > as a _special case_ if the LLDD/transport > layer > > > > didn't implement the > "autosense" model. > > > > > > Only SPI and USB? > > > > I don't understand this question. > > I meant, 'what transport protocols are categorized into > the transport > protocol that doesn't implement the > "autosense" model?' If any transport protocol conforms to SAM, it supports it. Either emulated in the transport itself or supported by the device (target) itself. But ideally, the SCSI mid-layer shouldn't have to get a CHECK CONDITION and then turn around and send REQUEST SENSE, due to the atomicity (per command) of the sense data, especially if the target supports queuing. There used to be a mechanism to support this in SAM but is now obsolete. > > > > > The most of LLDs using the transport protocol > that we care > > > about today > > > uses sense buffer in their own internal > structure. > > > > Yes. > > > > > > > > I think that the issue to solve to kill > > > scsi_cmnd:sense_buffer is how > > > to share (or export) such sense buffer with the > scsi > > > mid-layer. > > > > And therein lies the problem. Sense data is SCSI > specific, > > it should be left to SCSI, unless of course you can > > stipulate that _all_ block devices return sense data. > > Yeah, sense data is SCSI specific and it should be left to > SCSI. But > I'm not sure we need to stipulate that _all_ block > devices return > sense data. Today the block layer users (sg, bsg, etc) use > it only > when it's appropriate (or only if they want to use it). I agree. Luben - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
