Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/27/2011 10:33 AM, Paolo Bonzini wrote:
> On 07/27/2011 02:48 PM, Anthony Liguori wrote:
>>
>> So the idea here is that the PIC will multiplex a bunch of interrupts
>> into a single line?
>
> Yes, but the device needs to know the interrupt number so it can expose
> it through the enumerator interface. So the configuration cannot be simply
>
> pic->irq[n] = tty->irq;
>
> Logically, it's more similar to the ISA case, but I doubt the PIC
> distributes all interrupts to everyone in real hardware.
>
>> Is the enumerator something that has an interface to devices where
>> the devices hold this info? Or is the enumerator just a bank of
>> flash that's preprogrammed with fixed info?
>
> The former, at least in theory. Not sure if it also works that way in
> real hardware, but that's the model it exposes and the way the Android
> guys implemented it.
>
> The device model provides hotplug support, so it is definitely not just
> flash. Not sure again if this support is used in the hardware.

Sounds like I need to read a little about how this enumerator works.  I 
can't see how this would all operate without the enumerating being some 
form of a bus.

>
>> At each phase, we also get significantly better modularity.
>
> Fine, but when do we decide it's good enough to merge it?

I think we should evaluate the complexity vs. value trade off with the 
character device layer (when fully converted) and make the decision in a 
vacuum.

If the complexity seems too high, I can try to also convert the block 
layer and we can reevaluate.  I believe that just with the character 
device layer, it's a net win and I don't think it can be dramatically 
simplified.  The patches are actually not a lot of code.  The only 
complexity is conceptual and that's because it takes into account a lot 
of different problems.

I can even pair things down a bit by removing support for Interfaces and 
simplifying class initialization of need be for the first merge.

> And what if it
> turns out that it's not suitable for devices? We unified some things,
> but we also dug ourselves in NIH when we could have used GObject.
> (GObject definitely does not work for devices, but at least we don't
> need to write the infrastructure).

I tried to use GObject btw, I can share the results with you if you'd 
like.  Even with backends, I couldn't make properties work.  GObject 
uses GValues for properties which roughly models immutable values in a 
variant.  But I couldn't find a reasonable way to express Plugs and 
Sockets in terms of GValues.

I expect that at some point in the future, GObject will grow GVariant 
properties.  But I still think GVariant isn't quite what it needs to be 
since it still assumes immutable variants that can be copied.

I thought about just using GType but I thought using GType without using 
GObject was probably not a great long term plan as I doubt anyone else 
does this.

Regards,

Anthony Liguori

>
>> My only real concern is how to attack the device layer incrementally.
>> I don't think it's impossible but it requires careful thought.
>
> No idea here, honestly. :)
>
> Paolo
>