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

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

 



If we rename it to e.g. SG_GET_MAX_XFER_BYTES, it will still break
applications unless we also keep the wrong/ugly/confusing name (and
you lose the advantage/generality that the two ioctls can be used on
both sg and "pure" block devices; which seems to be the case of some
SG_* ioctls as well).

I don't see what it has to do with passthrough. Either way, it's just
a matter of whether you want to decouple it and make things more
flexible. The only real disadvantage is, you will have to do two
ioctls instead of one, but no more than that, and for good reasons.

I don't really care enough though. I mean, I'm okay with
SG_GET_MAX_XFER_BYTES *and* NO "improper" BLKSECTGET. If that will get
the patch series in, I am willing to send a new version. If not, I'm
just gonna drop this.

On Tue, 8 Sep 2020 at 16:43, Christoph Hellwig <hch@xxxxxx> wrote:
>
> 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