[Top][All Lists]
[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