On Mon, Aug 04, 2008 at 11:31:58AM +0300, Boaz Harrosh wrote: > Matthew Dharm wrote: > > If you've got an app that is sending a command, and you KNOW that command > > should produce >18 bytes of sense data, then there should be a way to > > specify to the SCSI core (and thus get passed to usb-storage) that sense > > data of >18 bytes should be requested. > > What?!! The number 18 comes totally from USB land at: > drivers/usb/storage/transport.c:601 via call to scsi_eh_prep_cmnd > Otherwise the entire kernel including scsi-ml and all user applications > request 96 bytes of sense, always. Well, yes. I think the value 96 must be (relatively) new... I think the value 18 originally came about by copying it from somewhere else, since it's not passed as a parameter from the scsi-ml and needed to be coded directly into usb-storage to support auto-sense. Perhaps you mis-interpreted my use of "should"? I mean "we should add a way" (not "a way should already exist"). Supporting auto-sense was a requirement since there are transport/protocol combinations where it's not really optional. And, once issued REQUEST_SENSE will clear the sense data, so it we needed to keep the data to put into the auto-sense buffer at those times when sense data needed to be passed to the scsi-ml. > So there is nothing the SCSI core or application can do about it. > It is USB fix time I'm afraid. Right now, there is nothing that SCSI core or an app can do about it. What I'm suggesting is that there be a parameter (in the scsi_host structure, perhaps?) that allows the core or an app to control this. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver I'm a pink gumdrop! How can anything be worse?!! -- Erwin User Friendly, 10/4/1998
Attachment:
pgpQMixbk2z8p.pgp
Description: PGP signature
