qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 00/20] qom: dynamic properties and compositio


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v3 00/20] qom: dynamic properties and composition tree
Date: Fri, 16 Dec 2011 08:54:43 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/16/2011 08:18 AM, Kevin Wolf wrote:
Am 16.12.2011 14:51, schrieb Anthony Liguori:
On 12/16/2011 06:24 AM, Paolo Bonzini wrote:
On 12/16/2011 11:36 AM, Kevin Wolf wrote:
I think actually this is not the biggest problem. child properties are
dynamic, and it's not a problem IMO if they are created like that.

That they are added in an init function is an indicator that they aren't
really dynamic.

That's true. However, another indicator is that anything that does not have a
struct field is also not really static. :)

So right now, child properties are all "dynamic" in this sense. This could
change when Anthony converts buses to QOM. The bus right now is embedded into
the HBA's struct, is not a pointer. This likely would change when buses are
QOM-ized, but then the bus would indeed be a 100% static child.

I think having a child property that can be NULL could be
reasonable.

I think Anthony convinced me this is not the case (unlike links). Even if buses
and similar objects are changed to pointers because the implementation needs
that, those pointers should never be NULL (or if they can, the child property
should not exist when they are NULL).

What I would like to get to eventually is:

struct ISASerial {
     Device parent;

     UART _child uart;
     ISABus _link *bus;
};

A child should be able to be part of the parent devices memory with its life
cycle bound to the parents life cycle.  This is why a child property shouldn't
be nullable.

I don't think being bound to the life cycle (that is, from realize on)
implies anything about being nullable.

For example, imagine two different types of UARTs with a compatible
interface, and you could choose whether to have one or the other on the
board. Maybe you could even use none at all (probably doesn't make a lot
of sense in this example, but I figure it might in other contexts).

What you're describing is what a link<> is. Whenever you want the ability to make a choice (including the choice of None), a link<> is the type of property to use.

But too much choice can be a bad thing. In many cases, you just want to have a child device for the purposes code sharing. An ISA serial device embedding a UART is a good example of this.

Yes, you could make a UARTInterface and have the ISA serial device expose a link<UARTInterface> but that's roughly equivalent to having every chip on your motherboard be connected with a DIP package instead of being soldered on the board. You could do it, but it would be very expensive and cumbersome.

So even though once the device is realized, the UART is bound to the
life cycle of your ISASerial, you wouldn't want to have the UART type
hard-coded, but leave the user a choice. Would this be modelled as a
link rather than a child?

Yes. I'm not terribly sure how this would work yet. A link and a child property both acquire references to a device and release a reference to a device at destruction time.

For a child property, the reference held by the parent is the only reference in existing. For non-child properties, the 'peripheral' container also holds a reference (since you want to be able to assign the device somewhere else in the device model).

I'm not sure tying life cycles for a user created device makes sense. If a user creates a device, IMO, the user should be the one to destroy the device.

Regards,

Anthony Liguori


Kevin





reply via email to

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