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

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

 



On Fri, 11 Sep 2020 at 14:48, Christoph Hellwig <hch@xxxxxx> wrote:
>
> On Fri, Sep 11, 2020 at 10:52:19AM +0800, Tom Yan wrote:
> > > How is that an advantage?  Applications that works with block devices
> > > don't really work with a magic passthrough character device.
> >
> > You must assume that there are applications already assuming that
> > work. (And it will, at least in some cases, if this series get
> > merged.)
>
> Why "must" I assume that?

Because of the name. The whole discussion was about the name. (Well,
also because 'I must assume that some applications has already been
"relying" on the wrong name.')

>
> > And you have not been giving me a solid point anyway, as I said, it's
> > just queue_*() at the end of the day; regardless of whether those
> > would work in all sg cases, we have been using them in the sg driver
> > anyway.
> >
> > And it's not like we have to guarantee that (the) ioctls can work in
> > every case anyway, right? (Especially when they aren't named SG_*).
>
> No.  While it is unfortunte we have all kinds of cases of ioctls working
> differnetly on different devices.
>
> >
> > I mean, what's even your point? How do you propose we fix this?
>
> I propose to not "fix" anything, because nothing is broken except for
> maybe a lack of documentation.

It won't really help anyway. Documenting something wrong won't make it
correct anyway. It's just wrong, semantically wrong, logically wrong;
expecting people to "rtfm and realize the difference" only makes it
even more wrong. End of story.

This was never about whether it is "broken" or whether we should
provide means to fetch the limit in the number of bytes or sectors. It
was always just about the name.

Just one last question. So should we not even replace the bit shift
with queue_logicial_block_size() in max_sectors_bytes()? Given that we
"must assume that it has been that way for long enough so applications
must have been dealing with the flaw on their own already and fixing
it will only breaks them"?



[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