From: Omar Sandoval <osandov@osandov.com>
To: Hannes Reinecke <hare@suse.de>
Cc: linux-block@vger.kernel.org, kernel-team@fb.com,
Ming Lei <ming.lei@redhat.com>
Subject: Re: [PATCH 1/2] loop: always return block size in LOOP_GET_STATUS
Date: Fri, 18 Aug 2017 00:47:00 -0700 [thread overview]
Message-ID: <20170818074700.GH2459@vader> (raw)
In-Reply-To: <3f01f907-0443-4961-d4fd-a5a3ffe8e688@suse.de>
On Fri, Aug 18, 2017 at 09:43:19AM +0200, Hannes Reinecke wrote:
> On 08/18/2017 09:38 AM, Omar Sandoval wrote:
> > On Fri, Aug 18, 2017 at 09:18:52AM +0200, Hannes Reinecke wrote:
> >> On 08/18/2017 08:15 AM, Omar Sandoval wrote:
> >>> From: Omar Sandoval <osandov@fb.com>
> >>>
> >>> When I was writing a test for the new loop device block size
> >>> functionality, I realized that the interface is kind of dumb:
> >>>
> >>> - lo_init[0] is never filled in with the logical block size we
> >>> previously set
> >>> - lo_flags returned from LOOP_GET_STATUS will have LO_FLAGS_BLOCKSIZE
> >>> set if we previously called LOOP_SET_STATUS with LO_FLAGS_BLOCKSIZE
> >>> set, which doesn't really mean anything
> >>>
> >>> Instead, for LOOP_GET_STATUS, let's always fill in lo_init[0] and set
> >>> the LO_FLAGS_BLOCKSIZE flag to indicate we support it.
> >>>
> >>> Signed-off-by: Omar Sandoval <osandov@fb.com>
> >>> ---
> >>> drivers/block/loop.c | 33 +++++++++++++++++----------------
> >>> 1 file changed, 17 insertions(+), 16 deletions(-)
> >>>
> >> Phew. 'Dumb interface'.
> >> 'tis wasn't me who designed the interface;
> >> Backwards compability are the watchwords here.
> >> Personally, I would have loved to design a new interface.
> >>
> >> I've got quite some flak for daring to break existing interfaces, most
> >> notably setting logical and physical blocksize per default (which I
> >> would _love_ to have done, seeing that it really makes sense here).
> >> But as this would change the behaviour I've gone through pains (and
> >> several _years_ of iterations) to get this sorted.
> >>
> >> So if you design a blocktest for that ensure that
> >> a) the sysfs attributes before and after the patch are _identical_
> >> b) the sysfs attributes will only change if the 'LO_FLAGS_BLOCKSIZE'
> >> flag has been set
> >> and
> >> c) validate the written blocksizes; this is required to be able to
> >> install bootloaders there
> >>
> >> This whole interface was designed such that you can prepare bootable
> >> diskimages for S/390 DASDs, which use a native 4k blocksize.
> >
> > Hi, Hannes,
> >
> > Wasn't insulting you at all, the only part of the interface I'm
> > complaining about is LOOP_GET_STATUS missing information :)
> >
> Sure. Just saying.
> But please make sure only to return that information if the
> LO_FLAGS_BLOCKSIZE flag is set; otherwise there's a rick of confusing
> losetup.
I actually checked losetup, it works just fine with LO_FLAGS_BLOCKSIZE
always set and lo_init[0] always filled in.
next prev parent reply other threads:[~2017-08-18 7:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 6:15 [PATCH 0/2] loop: LOOP_FLAGS_BLOCKSIZE fixes Omar Sandoval
2017-08-18 6:15 ` [PATCH 1/2] loop: always return block size in LOOP_GET_STATUS Omar Sandoval
2017-08-18 7:18 ` Hannes Reinecke
2017-08-18 7:38 ` Omar Sandoval
2017-08-18 7:43 ` Hannes Reinecke
2017-08-18 7:47 ` Omar Sandoval [this message]
2017-08-18 7:56 ` Hannes Reinecke
2017-08-18 8:05 ` Omar Sandoval
2017-08-18 8:12 ` Hannes Reinecke
2017-08-18 8:22 ` Omar Sandoval
2017-08-18 9:22 ` Karel Zak
2017-08-18 16:44 ` Omar Sandoval
2017-08-18 17:25 ` Karel Zak
2017-08-18 9:39 ` Karel Zak
2017-08-18 6:15 ` [PATCH 2/2] loop: fix hang if LOOP_SET_STATUS gets invalid blocksize or encrypt type Omar Sandoval
2017-08-18 7:20 ` Hannes Reinecke
2017-08-18 6:51 ` [PATCH 0/2] loop: LOOP_FLAGS_BLOCKSIZE fixes Omar Sandoval
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=20170818074700.GH2459@vader \
--to=osandov@osandov.com \
--cc=hare@suse.de \
--cc=kernel-team@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
/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.