[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: Anthony Liguori
Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState
Date: Wed, 13 Jun 2012 08:18:29 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/13/2012 07:53 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden>  writes:


I wanted to start a central thread as this discussion is spread in two
places right now.

I think I'm becoming convinced that realized belongs in DeviceState
and that BlockDriverState does not have a realized equivalent.

To me, realized represents Vcc.  When realized=true, the guest has
power and is active.  When realized=false, the guest has lost power.
The realize() event is the rising edge of Vcc, unrealized() is the
falling edge.

realize() should be used to take any actions that require all
parameters to be set that need to happen before the guest has power.
This later clause is extremely important.  unrealize() should be used
to unset anything setup in realize().

The destructor being invoked does not imply that unrealize() has happened.

I think BlockDriverState wants two separate signals: an opened signal
and an attached signal.

With BDS, there are a few phases:

opened = false
attached = false

All properties can be set here and no side effects occur.

It is not valid to do a read/write request to a BDS in this state.

opened = true
attached = false

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

We may eventually support multiple backing files (this is supported by VMDK, for instance).

So you need to explicitly open the file before you can even discover how many backing files there are.

Can you give another example of something we need to be able to do
between open and attach?

Depends on the image format. For something like QED/QCOW3 where there's an explicit meta-data repair phase, you may want to expose that flag. That's an operation that must happen after open but almost certainly before attach.

It is not valid to do a read/write request to a BDS in this state.

opened = true
attached = true

This means that the device is in-use by something in QEMU.  Requests
may be in flight as read/write requests are now allowed to be issued.

Most properties cannot be changed in this state (presumably).

opened = false
attached = true

Invalid state.

So there are three valid states and none of them map directly to the
concept of realized for devices.

I think this argues pretty clearly for realize() to not live in Object
and instead to allow base classes to implement whatever properties
make sense to them.

I'm not yet convinced.

QOM design started with two states: unrealized and realized.

No, that was never part of the QOM design actually. That was always in Device actually.

For block backends, you suggest we need to split the unrealized state.

I think it's just a coincidence that opened=false, attached=true is an invalid state. Consider CharDriverState as a counter example.

The equivalent of opened=false for CDS is a disconnected TCP CDS. While requests during opened=false is an error for BDS, for CDS, the data is simply discarded. So opened=false, attached=true is a perfectly valid state for CDS.

So it's not splitting unrealize.  It's really two independent parameters.

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.

When attached=true, you cannot set properties. There are many concrete states where this is true.

And this isn't even universally true. Some properties *can* be set when attached=true. For example, open flags is likely to be a good example of this.

So we really can make broad generalizations like the above.

2. While realized, the object "can do stuff", but its properties are
    typically immutable.

'typically' is the give-away word here.

My view of the world is that an Object may have 0 or more bits of state associated with it. Properties in general need to implement checks to determine whether setting the property is valid given the current arrangement of state.

I think 95% of the cases, this state will be in super classes and property permissions will fit into large classes (read-only when realized=true).


Anthony Liguori

reply via email to

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