All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: RFC: Making QEMU honour 'readonly' flag for disks
Date: Thu, 31 Jul 2008 12:45:11 +0100	[thread overview]
Message-ID: <20080731114511.GA18548@redhat.com> (raw)
In-Reply-To: <20080730091608.GI30193@redhat.com>

On Wed, Jul 30, 2008 at 10:16:08AM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 30, 2008 at 10:01:29AM +0100, Ian Jackson wrote:
> > Daniel P. Berrange writes ("[Xen-devel] RFC: Making QEMU honour 'readonly' flag for disks"):
> > > The Xen disk configuration syntax allows a block device to be marked as
> > > readonly, exclusive writable or shared writeable. The xen hotplug scripts
> > > will clash for clashing configs between domains, but  it is upto the
> > > backend drivers to actually enforce the readonly flag on I/O operations.
> > > The paravirt backend disk driver does this fine, but QEMU's emulated
> > > backend driver does not.
> > 
> > I still think this is a fix we should have but your patch is very
> > intrusive.  Is there some reason why you didn't just invent
> > BDRV_O_RDONLY_NO__ACTUALLY__READONLY ?  A new parameter to bdrv_new
> > seems quite wrong.
> > 
> > (It's a shame that the existing BDRV_O_RDONLY does something strange
> > and probably wrong, but we probably don't want to fix that in our
> > branch.)
> 
> Yeah, I'm actually attempting to fix that craziness, which is why
> I've not posted an update yet. I think it may actually be easier
> to fix that it appears....

Take a look at my patch on qemu-devel subject of

  "PATCH: Control over drive open modes for backing file"

If that gets into QEMU, the xen specific bit will merely involve changing
the xenstore.c file to pass correct flags to bdrv_open() instead of using
the default '0'.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

      reply	other threads:[~2008-07-31 11:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-24 11:36 RFC: Making QEMU honour 'readonly' flag for disks Daniel P. Berrange
2008-07-24 13:37 ` Ian Jackson
2008-07-24 13:41   ` Daniel P. Berrange
2008-07-24 13:43     ` Ian Jackson
2008-07-30  9:01 ` Ian Jackson
2008-07-30  9:16   ` Daniel P. Berrange
2008-07-31 11:45     ` Daniel P. Berrange [this message]

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=20080731114511.GA18548@redhat.com \
    --to=berrange@redhat.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xensource.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.