Hi, > > On Mon, Nov 26, 2018 at 11:02:42AM +0200, Avri Altman wrote: > > The size of the bsg job reply was set to SCSI_SENSE_BUFFERSIZE back then > > while it was part of the bsg_command. However, for the scsi transport > > that uses it, it does not carry the scsi sense information. > > > > Rename it to clarify this point, and while at it, make it a little bit > > larger, so it'll be able to carry some useful information, > > e.g. ufs descriptors, should be needed. > > So this will allocate a huge buffer for replies just in for your > read case. Also shouldn't the descriptor being read be placed in > the actual data buffer in the bio, not in this magic field? Theoretically some string descriptors can be 254 Bytes long, But those are much smaller in reality. I used 16x20 as an upper bound. Config descriptor is the actually the largest - 144 Bytes. The request size btw, is unlimited.
There isn't really a data phase here. read descriptor is the only case in the protocol in which some data is returning outside of the upiu structure. I could make it return hang over the job->reply_payload, Would that be a better option? And if doing so (adding a data phase that is), While at it, shouldn't I add command upiu as well? Thanks, Avri
