qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/3] block: set bs->read_only before .bdrv_open()
Date: Thu, 27 Oct 2011 12:53:16 +0200	[thread overview]
Message-ID: <4EA9381C.8050901@redhat.com> (raw)
In-Reply-To: <CAJSP0QWuwR0oKHVGUf-tPih9Dy1nDpL+4dopd8q9hgDFvE9fjQ@mail.gmail.com>

Am 27.10.2011 12:45, schrieb Stefan Hajnoczi:
> On Thu, Oct 27, 2011 at 11:18 AM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 27.10.2011 11:54, schrieb Stefan Hajnoczi:
>>> Several block drivers set bs->read_only in .bdrv_open() but
>>> block.c:bdrv_open_common() clobbers its value.  Additionally, QED uses
>>> bdrv_is_read_only() in .bdrv_open() to decide whether to perform
>>> consistency checks.
>>>
>>> The correct ordering is to initialize bs->read_only from the open flags
>>> before calling .bdrv_open().  This way block drivers can override it if
>>> necessary and can use bdrv_is_read_only() in .bdrv_open().
>>>
>>> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>>> ---
>>>  block.c |    4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/block.c b/block.c
>>> index 70aab63..3207e99 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -500,6 +500,8 @@ static int bdrv_open_common(BlockDriverState *bs, const char *filename,
>>>          open_flags |= BDRV_O_RDWR;
>>>      }
>>
>> Not directly related, but the context made me wonder when we're making a
>> BlockkDriverState writeable unconditionally. This is the full context:
>>
>>
>>    /*
>>     * Snapshots should be writable.
>>     */
>>    if (bs->is_temporary) {
>>        open_flags |= BDRV_O_RDWR;
>>    }
>>
>> Does anyone understand what the point of this is? If the user requested
>> read-only, he certainly wants to have read-only, even if he specified
>> -snapshot as well.
> 
> Perhaps this is an attempt to support -drive
> file=pristine.img,readonly=on,snapshot=on.  The idea being that the
> user absolutely wants to keep pristine.img unmodified.  But the nature
> of backing files means we should automatically get this.

I would have said that it breaks this command line. It all depends on
what your expectation of the semantics of these options is. Mine would
be that the disk is presented read-only to the guest (and the snapshot
is done but useless).

Kevin

  reply	other threads:[~2011-10-27 10:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-27  9:54 [Qemu-devel] [PATCH 1/3] qemu-io: delete bs instead of leaking it Stefan Hajnoczi
2011-10-27  9:54 ` [Qemu-devel] [PATCH 2/3] block: set bs->read_only before .bdrv_open() Stefan Hajnoczi
2011-10-27 10:18   ` Kevin Wolf
2011-10-27 10:41     ` Stefan Hajnoczi
2011-10-27 10:45     ` Stefan Hajnoczi
2011-10-27 10:53       ` Kevin Wolf [this message]
2011-10-27  9:54 ` [Qemu-devel] [PATCH 3/3] block: reinitialize across bdrv_close()/bdrv_open() Stefan Hajnoczi

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=4EA9381C.8050901@redhat.com \
    --to=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.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 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).