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.