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

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

 



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()*.

On Mon, 7 Sep 2020 at 14:09, Christoph Hellwig <hch@xxxxxx> wrote:
>
> On Sun, Sep 06, 2020 at 09:27:14AM +0800, Tom Yan wrote:
> > Provide an ioctl to get the logical sector size so that the maximum
> > bytes per request can be derived.
> >
> > Follow-up of the BLKSECTGET fix.
>
> I don't think this has any business going in.  /dev/sg is a generic
> interface that is not specific to block based command sets.  Just issue
> your command set specific command to query the logical block size if
> you care about it.



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

  Powered by Linux