Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 07, 2020 at 05:01:34PM +0800, Tom Yan wrote:
> Feel free to omit this. But then you will probably want to ditch
> BLKSECTGET as well, and then any usage of queue_max_sectors(), and
> maybe more/all queue_*().
> 
> I'm not really interested in discussing/arguing whether
> general/ideally-speaking it's appropriate/necessary to keep BLKSECTGET
> / add BLKSSZGET. The only reason I added this is that, when BLKSECTGET
> was introduced to sg long time ago, it was wrongly implemented to
> gives out the limit in bytes, so now when I'm fixing it, I'm merely
> making sure that whatever has been relying on the ioctl (e.g. qemu)
> will only need to do one more ioctl (instead of e.g. doing SCSI in its
> non-SCSI-specific part), if they want/need the limit in bytes. If they
> can be implemented more "generic"-ly, feel free to improve/extend them
> to make them "SG_*-qualified".
> 
> Even if you can do SCSI from the userspace, or even should, I don't
> see any reason that we shouldn't provide an ioctl to do
> queue_logical_block_size() *while we provide one to do
> queue_max_sectors()*.

Well, the different definition in bytes for sg actually makes sense
to me, as a bytes based limit is what fundamentally makes sense for
the passthrough interface.  Only that it reuses the same cmd value
is a bit confusing.  So instead of changing anything and potentially
breaking applications I'd suggest to just better document the semantics.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux