On Thu, Sep 15, 2011 at 08:17:13AM -0500, Anthony Liguori 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.
>
I do not need get_fw_dev_path() as such. I need the way to generate OF
device path for a device. I hope you are not saying that the fact that
we generate OF path is the problem of qdev. OF device path is an ABI
between QEMU and a firmware. Firmware can't do much with QOM device
paths.
> >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.
>
Of course it is chosen by human, just like QOM is the representation
chosen by human :) But human made sure that it presents enough information
for OS level software to unambiguously determine a device a path points
too.
> If you look at what other folks have done with OF integration in
> QEMU, you'll see a recurring theme of two OF trees, one used to
> create the hardware and the other that is actually exposed to the
> guest. The reason you need two is because guests sometimes expect
> very specific things that you really can't generate programmatically
> in every circumstance.
>
> >The difference
> >between OF device path and the examples above is that OF device path has
> >a meaning outside of QEMU and can be used by firmware to find a device
> >a path refers too. Will QOM be able to generate them?
>
> All of the information needed to generate an OF tree is available as
> device properties. To the extent that you need to knowledge of each
> bus to generate a OF path component, you'll need some extra
> knowledge of each bus to do that (just like with qdev today). But
> that knowledge will definitely not be part of QOM.
>
With qdev buses are different from devices so it is very clear where to
put that extra knowledge (inside get_fw_dev_path callback of a bus). How
are you going to do that with QOM? As you said in your other email QOM
is a graph, so dumb recursion will not work like it did in qdev. At each
node you need to know which link to take.
> Paths are not part of QOM. They're representations used by client
> software to navigate the QOM graph. There is no real need to make
> paths part of QOM explicitly.
>
I am not saying there is. I just what to make sure that we will not
regress by moving to QOM.
--
Gleb.
