[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Wed, 14 Sep 2011 17:11:06 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/14/2011 04:15 PM, Jan Kiszka wrote:
On 2011-09-14 21:42, Anthony Liguori wrote:
Such names can get fairly long I'm afraid...

A user should never even see these names.  A user probably will always
interact with devices via paths.

<scratching head>
But will those automatic names be used at all then?

Yes, because QEMU is not going to know anything about path names :-)

Path names should be a concept that exists entirely in the client. That may be HMP or that may be a command line tool (like the proposed qemu script).

The only management interface exposed to the client is:

create_object(type, name)
value = get_object_property(name, property_name)
void set_object_property(name, property_name, value)
props = list_object_properties(name)
names = list_objects()

So names are very important from a QMP perspective, but not something users every really see.

We can also look at doing things like user-defined aliases or something
like that.

...or a way to set the name of an auto-generated device via its pathname.

The auto-generated name is already basically generated from a pathname. But that path isn't necessarily the obvious one from a user's point of view.

Since a bus is-a device in QOM, there is no notion of having multiple
under the same device.  A device can implement multiple bus interfaces,
but can
only be a single bus of any given bus interface.

Device names are completely independent of pathnames.  For devices that
are no
user created, device names should be treated as opaque blobs with
absolutely no
semantic meaning.

All device relationships are identified as named properties.  A QOM path
consists of a named device,

With a system root device called '/'. So '/' is another
character(-sequence) that is forbidden in device names.

Yes, but there is no system root device.

There is always a generic link to some root device. I think it would be
more regular to make that link an abstract device called '/' - maybe
even one that can hold a larger number of children. Keeps the door open
for crazy multi-root systems models.

From a client perspective, yes. The scripts I showed at KVM Forum had '/' return the list of all user-created devices as the contents. It's a nice feature but I think it's something that lives in a client, not in the object model.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]