qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState


From: Kevin Wolf
Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState
Date: Wed, 13 Jun 2012 17:44:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Am 13.06.2012 14:53, schrieb Markus Armbruster:
> Anthony Liguori <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]