From: "Michael S. Tsirkin" <mst@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Naphtali Sprei <nsprei@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH v2 2/4] Clean-up a little bit the RW related bits of BDRV_O_FLAGS. BDRV_O_RDONLY gone (and so is BDRV_O_ACCESS). Default value for bdrv_flags (0/zero) is READ-ONLY. Need to explicitly request READ-WRITE.
Date: Mon, 18 Jan 2010 12:48:17 +0200 [thread overview]
Message-ID: <20100118104816.GC5874@redhat.com> (raw)
In-Reply-To: <m3d4174s6k.fsf@blackfin.pond.sub.org>
On Mon, Jan 18, 2010 at 11:34:59AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > On Sun, Jan 17, 2010 at 04:48:13PM +0200, Naphtali Sprei wrote:
> >> Instead of using the field 'readonly' of the BlockDriverState struct for passing the request,
> >> pass the request in the flags parameter to the function.
> >>
> >> Signed-off-by: Naphtali Sprei <nsprei@redhat.com>
> >
> > Many changes seem to be about passing 0 to bdrv_open. This is not what
> > the changelog says the patch does. Better split unrelated changes to a
> > separate patch.
> >
> > One of the things you seem to do is get rid of BDRV_O_RDONLY. Why is
> > this an improvement? Symbolic name like BDRV_O_RDONLY seems better than
> > 0.
>
> BDRV_O_RDWR is a flag, just like BDRV_SNAPSHOT. We don't have
> BDRV_DONT_SNAPSHOT, either.
Well, this just mirros the file access macros: we have RDONLY, WRONLY
and RDRW. I assume this similarity is just historical?
> The old code can't quite devide whether BDRV_O_RDWR is a flag, or
> whether to use bits BDRV_O_ACCESS for an access mode, with possible
> values BDRV_O_RDONLY and BDRV_O_RDWR. I asked Naphtali to clean this
> up, and recommended to go with flag rather than access mode:
>
> In my opinion, any benefit in readability you might hope gain by
> having BDRV_O_RDONLY is outweighed by the tortuous bit twiddling you
> need to keep knowledge of its encoding out of its users.
>
> http://lists.nongnu.org/archive/html/qemu-devel/2009-12/msg02504.html
>
> [...]
> >> @@ -985,6 +986,7 @@ static int img_snapshot(int argc, char **argv)
> >> return 0;
> >> }
> >> action = SNAPSHOT_LIST;
> >> + bdrv_oflags &= ~BDRV_O_RDWR; /* no need for RW */
> >
> > bdrv_oflags = BDRV_O_RDONLY would be clearer, and no need
> > for comment then?
>
> BDRV_O_RDWR is a flag, and this is the clean way to clear it.
>
> "bdrv_oflags = BDRV_O_RDONLY" assumes that everything but the access
> mode in bdrv_oflags is clear. Tolerable, because the correctness
> argument is fairly local, but the clean way to do it would be
>
> bdrv_oflags = (bdrv_oflags & ~ BDRV_O_ACCESS) | BDRV_O_RDONLY;
>
> That's what I meant by "tortuous bit twiddling".
>
> [...]
Thinking about it, /* no need for RW */ comment can just go. But other
places in code just do flags = 0 maybe they should all do &=
~BDRV_O_RDWR? I don't really have an opinion here but I do think this
patch needs a better commit log (all it says "pass the request in the
flags parameter to the function") and be split up:
patch 1 - get rid of BDRV_O_RDONLY/BDRV_O_ACCESS
patch 2 - pass the request in the flags parameter to the function
patch 3 - any other fixups
As it is, sometimes e.g. BDRV_O_RDWR is replaced with 0 sometimes as
well, and it's hard to see why.
--
MST
next prev parent reply other threads:[~2010-01-18 10:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-17 14:48 [Qemu-devel] [PATCH v2 0/4] Modifications to the drives' readonly attribute Naphtali Sprei
2010-01-17 14:48 ` [Qemu-devel] [PATCH v2 1/4] Make CDROM a read-only drive Naphtali Sprei
2010-01-17 14:48 ` [Qemu-devel] [PATCH v2 2/4] Clean-up a little bit the RW related bits of BDRV_O_FLAGS. BDRV_O_RDONLY gone (and so is BDRV_O_ACCESS). Default value for bdrv_flags (0/zero) is READ-ONLY. Need to explicitly request READ-WRITE Naphtali Sprei
2010-01-17 14:48 ` [Qemu-devel] [PATCH v2 3/4] Added drives' readonly option Naphtali Sprei
2010-01-17 14:48 ` [Qemu-devel] [PATCH v2 4/4] Disable fall-back to read-only when cannot open drive's file for read-write Naphtali Sprei
2010-01-17 14:59 ` [Qemu-devel] " Michael S. Tsirkin
2010-01-18 11:45 ` Naphtali Sprei
2010-01-17 15:32 ` [Qemu-devel] Re: [PATCH v2 2/4] Clean-up a little bit the RW related bits of BDRV_O_FLAGS. BDRV_O_RDONLY gone (and so is BDRV_O_ACCESS). Default value for bdrv_flags (0/zero) is READ-ONLY. Need to explicitly request READ-WRITE Michael S. Tsirkin
2010-01-18 10:34 ` Markus Armbruster
2010-01-18 10:48 ` Michael S. Tsirkin [this message]
2010-01-18 12:47 ` Markus Armbruster
2010-01-20 2:05 ` Jamie Lokier
2010-01-20 7:26 ` Markus Armbruster
2010-01-20 10:32 ` Michael S. Tsirkin
2010-01-20 12:09 ` Markus Armbruster
2010-01-20 12:25 ` Michael S. Tsirkin
2010-01-20 13:05 ` Markus Armbruster
2010-01-20 13:37 ` Jamie Lokier
2010-01-18 11:32 ` Naphtali Sprei
2010-01-20 2:06 ` [Qemu-devel] [PATCH v2 1/4] Make CDROM a read-only drive Jamie Lokier
2010-01-20 14:55 ` Anthony Liguori
2010-01-20 17:05 ` [Qemu-devel] [PATCH v2 0/4] Modifications to the drives' readonly attribute Christoph Hellwig
2010-01-21 13:19 ` Naphtali Sprei
2010-01-21 13:37 ` Christoph Hellwig
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=20100118104816.GC5874@redhat.com \
--to=mst@redhat.com \
--cc=armbru@redhat.com \
--cc=nsprei@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).