Hi Doug,
On Sat, 5 Sep 2020 at 00:28, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote:
>
> On 2020-09-04 12:42 a.m., Tom Yan wrote:
> > Hi,
> >
> > Is BLKSECTGET in sg intentionally kept "broken" (i.e. it gives out
> > max_sectors in bytes) or is it just a miss? I'm just wondering if I
> > should send a patch to fix it (and implement BLKSSZGET).
> >
> > Also, shouldn't max_sectors_bytes() in both drivers/scsi/sg.c and
> > block/scsi_ioctl.c use queue_logical_block_size() instead?
>
> Tom,
> I have no idea! One of the great things about maintaining a driver in
> Linux is that virtually anyone can send patches and get them accepted
> without and Ack from the maintainer. And when bugs are found in those
> patches, the culprits can't be found or have no inclination to fix them.
>
> 'git blame' will show you that I had nothing to do with the BLK*
> ioctl()s added to the sg driver. That said, if they are broken, they
> should be fixed. I would be interested in getting some test code as
You can test them easily with `blockdev` (--getmaxsect and --getss) in
util-linux.
max_sectors_bytes() are used in sg_add_sfp() and the
SG_{GET,SET}_RESERVED_SIZE ioctls. I am not familiar with those but I
don't see why they shouldn't use the queue_logical_sector_size() (when
they use queue_max_sectors()).
For the BLKSECTGET fix, I think the sg version needs to be bumped (so
that userspace programs like qemu can work as properly as possible
with different versions). Can you point me to some guidance on how
exactly it should be bumped (e.g. which component(s), the "step
size"...)? Or would you do that after the patches are accepted?
> I'm not familiar with using those ioctl()s.
>
> Would you like to send some patches?
They are on the way.
>
> Doug Gilbert
>
>
Regards,
Tom
