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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Fri, Sep 16, 2011 at 09:12:19PM -0500, Anthony Liguori wrote:
> 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.

Yes, but that thinking can be applied recurseivly. Forever. There's always
going to be new and better interfaces in the future.


> >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.

Yes. Don't missunderstand me, I like the way QOM is heading. I think
it is reasonable to wait for QOM and an RPC interface to come along.
But it also depends on the time it takes. These topics have, and can be
discussed for a long time while we have users waiting for features.

Last time this was discussed, qdev was the answer. Now, QOM is the
answer. In the future QOM2 will be the answer.

Let's give QOM a shot, but if it doesn't happen within reasonable
time, we'll have to consider reviweing qdev approches., IMHO.
I don't wan't to hurry QOM, but I will ping in 6 months or a year
or so.

Cheers