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

[Edgar E. Iglesias]

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<address@hidden>  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 in the
sense that if the external interfaces won't be available until years
from now, we should take iternmediate steps.

We've all got imaginary interfaces in our minds, but as long as
these are nowhere near reality, IMO we need to review approaches
towards the current model with a more current perspective.

Cheers