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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux