All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Yan <tom.ty89@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-scsi@vger.kernel.org, dgilbert@interlog.com,
	Bart Van Assche <bvanassche@acm.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	akinobu.mita@gmail.com, linux-api@vger.kernel.org
Subject: Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET
Date: Fri, 11 Sep 2020 10:52:19 +0800	[thread overview]
Message-ID: <CAGnHSE=pcW0zJMSaowdsRXFa=TmOeidekgvDuEPB8PU7mheXNA@mail.gmail.com> (raw)
In-Reply-To: <20200910052835.GB18283@lst.de>

On Thu, 10 Sep 2020 at 13:28, Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Sep 10, 2020 at 09:59:05AM +0800, Tom Yan wrote:
> > 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).
>
> 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.)

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

I mean, what's even your point? How do you propose we fix this? Should
we just leave it broken/wrong/rotten as-is (including the case that
you don't consider it being so)? If that's what you are trying to say
then please just say it, I'll just walk away quietly. I'm really kind
of done with this sort of looping that leads to nowhere.

>
> > 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.
>
> You must assume that there are applications already that depend in the
> "weird" BLKSECTGET on sg, given that it has been around so long.  Any
> change to the semantics will break them.

While you forgot to assume that there are applications assuming
BLKSECTGET is as "weird" in the block layer at the same time. (That's
exactly what has happened in qemu.) You don't get the slightest
advantage in "trying not to break things" by doing the wrong thing. It
only goes on making more things broken.

  reply	other threads:[~2020-09-11  2:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04  4:42 About BLKSECTGET in sg Tom Yan
2020-09-04 16:28 ` Douglas Gilbert
2020-09-04 19:21   ` Tom Yan
2020-09-04 20:05     ` [PATCH 1/4] scsi: sg: fix BLKSECTGET ioctl Tom Yan
2020-09-04 20:05       ` [PATCH 2/4] scsi: sg: implement BLKSSZGET Tom Yan
2020-09-05 18:37         ` Douglas Gilbert
2020-09-04 20:05       ` [PATCH 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes() Tom Yan
2020-09-05 18:37         ` Douglas Gilbert
2020-09-04 20:05       ` [PATCH 4/4] block/scsi_ioctl.c: " Tom Yan
2020-09-05 18:37         ` Douglas Gilbert
2020-09-05 18:37       ` [PATCH 1/4] scsi: sg: fix BLKSECTGET ioctl Douglas Gilbert
2020-09-05 19:32       ` Bart Van Assche
2020-09-05 20:36         ` Douglas Gilbert
2020-09-06  1:19           ` Tom Yan
2020-09-06  1:25             ` [PATCH RESEND " Tom Yan
2020-09-06  1:25               ` [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET Tom Yan
2020-09-06  1:25               ` [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes() Tom Yan
2020-09-06  1:25               ` [PATCH RESEND 4/4] block/scsi_ioctl.c: " Tom Yan
2020-09-06  1:27             ` [PATCH RESEND 1/4] scsi: sg: fix BLKSECTGET ioctl Tom Yan
2020-09-06  1:27               ` [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET Tom Yan
2020-09-07  6:09                 ` Christoph Hellwig
2020-09-07  9:01                   ` Tom Yan
2020-09-08  8:42                     ` Christoph Hellwig
2020-09-10  1:59                       ` Tom Yan
2020-09-10  5:28                         ` Christoph Hellwig
2020-09-11  2:52                           ` Tom Yan [this message]
2020-09-11  6:48                             ` Christoph Hellwig
2020-09-11 17:52                               ` Douglas Gilbert
2020-09-11 21:33                                 ` Alan Stern
2020-09-16  5:47                               ` Tom Yan
2020-09-06  1:27               ` [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes() Tom Yan
2020-09-06  6:26                 ` Greg KH
2020-09-06  7:01                   ` Tom Yan
2020-09-06  7:40                     ` [PATCH v2 1/4] scsi: sg: fix BLKSECTGET ioctl Tom Yan
2020-09-06  7:40                       ` [PATCH v2 2/4] scsi: sg: implement BLKSSZGET Tom Yan
2020-09-06  7:40                       ` [PATCH v2 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes() Tom Yan
2020-09-06  7:40                       ` [PATCH v2 4/4] block/scsi_ioctl.c: " Tom Yan
2020-09-06  7:51                     ` [PATCH v3 1/4] scsi: sg: fix BLKSECTGET ioctl Tom Yan
2020-09-06  7:51                       ` [PATCH v3 2/4] scsi: sg: implement BLKSSZGET Tom Yan
2020-09-06  7:51                       ` [PATCH v3 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes() Tom Yan
2020-09-06  7:51                       ` [PATCH v3 4/4] block/scsi_ioctl.c: " Tom Yan
2020-09-06  1:27               ` [PATCH RESEND " Tom Yan
2020-09-06  5:09             ` [PATCH 1/4] scsi: sg: fix BLKSECTGET ioctl Douglas Gilbert
2020-09-06  7:16               ` Tom Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGnHSE=pcW0zJMSaowdsRXFa=TmOeidekgvDuEPB8PU7mheXNA@mail.gmail.com' \
    --to=tom.ty89@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=bvanassche@acm.org \
    --cc=dgilbert@interlog.com \
    --cc=hch@lst.de \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.