Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/16/2011 08:11 PM, Edgar E. Iglesias wrote:
> On Fri, Sep 16, 2011 at 11:10:19AM -0500, Anthony Liguori wrote:
>> On 09/16/2011 09:46 AM, John Williams wrote:
>>> On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori<anthony@codemonkey.ws>   wrote:
>>>> On 09/15/2011 01:31 AM, Gleb Natapov wrote:
>>>>>
>>>>> On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
>>>>>>
>>>>>> All device relationships are identified as named properties.  A QOM
>>>>>> path name
>>>>>> consists of a named device, followed by a series of properties which
>>>>>> may or may
>>>>>> not refer to other devices.  For instance, all of the following are
>>>>>> valid paths:
>>>>>>
>>>>>>   /i440fx/piix3/i8042/aux
>>>>>>   /i440fx/slot[1.0]/i8042/aux
>>>>>>   /i440fx/slot[1.0]/bus/piix3/i8042/aux
>>>>>>
>>>>> Have you looked at device paths generated by get_fw_dev_path() in qdev?
>>>>
>>>> get_fw_dev_path() won't exist in QOM.  The fact that it exists in qdev is a
>>>> problem with qdev.
>>>>
>>>>> This function generates Open Firmware device path.
>>>>
>>>> The function generates *a* OF device path.  OF is not a canonical
>>>> representation of arbitrary hardware.  It's a representation chosen (usually
>>>> by a human) of what information about the hardware is needed by the OS-level
>>>> software.
>>>
>>> That need not be the case - with the
>>>
>>>   link=<&target>
>>>
>>> syntax, device trees can be topologically accurate descriptions - this
>>> is part of our still-unreviewed patchset,
>>
>> It's not unreviewed.  Any type of machine configuration needs to be
>> done using qdev/qom factory interfaces, not implementing custom
>> logic tied to a config format.
>>
>> Can you construct OF paths based on link attributes?  What would
>> that look like in practice?
>>
>>> Another counter-example - our device trees are autogenerated out of a
>>> high level system synthesis tool.  One path is a device tree for QEMU
>>> and kernel configuration, the other is to actually create the system
>>> based on a high level design specification.
>>
>> That's all well and good, but the mechanism that I think is
>> important to have in QEMU is a programmatic interface for
>> constructing and manipulating the guest devices.  A config file is
>> not a programmatic interface.  You can implement config file support
>> in terms of a programmatic interface but implementing the later in
>> terms of the former is extremely painful.
>
> I agree, but I also thinik that we have to be a bit pragmatic

It's not pragmatic to leave something that's mostly broken alone and tack on 
something new that replicates the function to gain a new feature.

It just results in more cruft and makes it harder to ever fix the real problem.

> in the
> sense that if the external interfaces won't be available until years
> from now, we should take iternmediate steps.

These are the intermediate steps:

http://wiki.qemu.org/Features/QOM#TODO

We really aren't that far away from fixing qdev and making all of these problems 
go away.

> We've all got imaginary interfaces in our minds, but as long as
> these are nowhere near reality,

They are very much reality and they aren't imaginary.  Code exists, we just need 
to move in a common direction here and spend some time fixing past mistakes.

Regards,

Anthony Liguori