Message ID | 20210421174749.11221-1-hare@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | SCSI result cleanup, part 2 | expand |
On 4/21/21 10:47 AM, Hannes Reinecke wrote: > This patchset is the first part of that, and is intentionally posted > as an RFC as it directly competes with Barts patchset. I'm fine with this patch series being merged upstream first. Thanks, Bart.
On 4/21/21 10:47 AM, Hannes Reinecke wrote: > My plan here is move every driver to use accessors for the > remaining bytes in the SCSI result, and with that move the > SCSI result over into two separate values. This patch series modifies scsi_execute() such that it either returns a negative Unix error code or a positive SCSI status value that includes the host byte and status byte. I think that a union is a good way to model such return values. I'd like to use something similar to the scsi_status union from my patch series to model such return values. I think that union is also appropriate as a replacement for the 'result' member of struct scsi_cmnd. Thanks, Bart.
On 4/22/21 12:26 AM, Bart Van Assche wrote: > On 4/21/21 10:47 AM, Hannes Reinecke wrote: >> My plan here is move every driver to use accessors for the >> remaining bytes in the SCSI result, and with that move the >> SCSI result over into two separate values. > > This patch series modifies scsi_execute() such that it either returns a > negative Unix error code or a positive SCSI status value that includes > the host byte and status byte. I think that a union is a good way to > model such return values. I'd like to use something similar to the > scsi_status union from my patch series to model such return values. I > think that union is also appropriate as a replacement for the 'result' > member of struct scsi_cmnd. > And that was precisely the point of my patchset: do _not_ use driver byte nor message byte in the SCSI midlayer. So the midlayer can be reduced to handling just the host byte and the status byte. Whether this is by means of a union or something else doesn't really matter; this patchset doesn't prevent any of this from happening. I'm open to discussion on whether we need to expose the original driver byte to userspace; I've already attempted to do this for DRIVER_SENSE, and if needs be DRIVER_ERROR can be fudged in, too. But I do think that message byte handling should be killed from the midlayer, as it really is SCSI parallel specific and shouldn't be exposed to the midlayer at all. Cheers, Hannes
On 4/22/21 1:49 AM, Hannes Reinecke wrote: > So the midlayer can be reduced to handling just the host byte and the > status byte. Whether this is by means of a union or something else > doesn't really matter; this patchset doesn't prevent any of this from > happening. Something that is important to mention is that struct scsi_request is not only used by the SCSI code but also by the IDE code. Changing the 'result' member of struct scsi_request also affects the IDE code. These are the SCSI and block layer calls in the IDE code that I am aware of and that assume that a struct scsi_request immediately follows struct request: * scsi_req_init(). * scsi_cmd_blk_ioctl(). I have not yet tried to evaluate how much work it would take to split the code in block/scsi_ioctl.c such that it supports different layouts for the data that follows struct request for IDE and SCSI. Thanks, Bart.