qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object
Date: Mon, 11 Jun 2012 08:21:21 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/11/2012 03:25 AM, Kevin Wolf wrote:
Am 10.06.2012 19:38, schrieb Andreas Färber:
Am 10.06.2012 17:49, schrieb Paolo Bonzini:
Il 08/06/2012 03:19, Anthony Liguori ha scritto:

+typedef enum ObjectState {
+    OBJECT_STATE_INITIALIZED = 1,
+    OBJECT_STATE_REALIZED,
+} ObjectState;

I think using a bool would be better since it reduces the temptation to
add additional states.

In fact someone already discussed having a third state for block
devices... :)

I would expect that file_opened state to remain internal to the block
layer. Thought we discussed that on IRC?

I think I still don't understand well enough what 'realized' is really
supposed to mean.

realized is essentially the Vcc pin for the device.

When realized = true, it means power has been applied to the device (and the guest potentially is interacting with it).

When realized = false, it means that power is not applied to the device and the guest is not running.


Does some magic happen when an object gets realised? From outside,
what's the difference between an INITIALIZED and a REALIZED object? Is
it more or less an implementation detail of the base class or is it
something that affects the object model itself?

On the rising edge of realized, you typically will validate any parameters and do any actions necessary based on the parameters. As long as the guest isn't running, we want the ability to make changes to the devices that we normally couldn't change while the guest is running (like updating the CharDriverState pointer).

I think the file_opened state should have more or less the same status
as the realisation of an object. They are quite similar, so they should
both be an implementation detail of their respective class, or they
should both be baked into the object model.

I think we need to think about what realized means to a non-Device. Does file_opened have the same logical semantics as the above?


A comment in this patch says it means that an object is fully
constructed.

That's not really the best wording.  See above.

Regards,

Anthony Liguori

So if we add a file_opened state in the block layer, in
order to keep this consistent, it would have to be a state that comes
between INITIALIZED and REALIZED.

Where would we have checks, for example whether the image that you
assign to a block device is really opened? Would QOM commands to create
a link only link to already realised objects? Would each single block
device have to check this during its own realisation phase? Would we
check object_is_realized() or rather bdrv_file_is_opened()? If the
latter, it can't be generic monitor code that checks it.

Let's start with this, I'm sure I'll have more questions...

Kevin




reply via email to

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