All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	"Stefan Hajnoczi" <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState
Date: Wed, 13 Jun 2012 17:44:59 +0200	[thread overview]
Message-ID: <4FD8B57B.5000303@redhat.com> (raw)
In-Reply-To: <m3vcivz82s.fsf@blackfin.pond.sub.org>

Am 13.06.2012 14:53, schrieb Markus Armbruster:
> Anthony Liguori <anthony@codemonkey.ws> writes:
>> Properties that affect file opening (flags and filename) cannot be
>> changed after this point.  Depending on the contents of the file, a
>> backing_file property may be created after opened = true.  The
>> backing_file that gets created does *not* automatically have opened =
>> true.  A user explicitly needs to set that.
>>
>> This behavior is necessary to allow overriding backing files.
> 
> Could you explain why we need to override backing files between open and
> attach?
> 
> Can you give another example of something we need to be able to do
> between open and attach?

It's just one example of an option that can get a default value from the
image file, but can we overridden by the user (e.g. by libvirt in order
to pass a file descriptor instead).

The same is true for the backing file format, for an option whether QED
mode may be used and probably quite a few more.

> I'm not yet convinced.
> 
> QOM design started with two states: unrealized and realized.
> 
> For block backends, you suggest we need to split the unrealized state.
> I'm not sure that's actually necessary.  But even if it is, the result
> still satisfies the unrealized/realized contract:
> 
> 1. While unrealized, all you can do is set properties.  Setting a
>    property may fail.
> 
> 2. While realized, the object "can do stuff", but its properties are
>    typically immutable.
> 
> Yes, that's a pretty vague contract.  But TYPE_OBJECT is a pretty
> abstract thing, so some vagueness may be unavoidable.  If you can come
> up with a tighter one, excellent.
> 
> Note that a BDS satisfies 1. whether it's opened or not.

There's a difference concerning which properties can be written.
Initially you can write to all properties, after opening the image file
some (like the filename) become read-only, and after
attach/realize/whatever you call it more of them become read-only.

Kevin

      parent reply	other threads:[~2012-06-13 15:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 22:05 [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState Anthony Liguori
2012-06-12  0:29 ` Andreas Färber
2012-06-12  1:26   ` Anthony Liguori
2012-06-12  6:10 ` Paolo Bonzini
2012-06-12  8:07   ` Kevin Wolf
2012-06-12  8:02 ` Kevin Wolf
2012-06-13 12:53 ` Markus Armbruster
2012-06-13 12:55   ` Paolo Bonzini
2012-06-13 13:18   ` Anthony Liguori
2012-06-13 15:44   ` Kevin Wolf [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=4FD8B57B.5000303@redhat.com \
    --to=kwolf@redhat.com \
    --cc=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --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 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.