Re: [Qemu-devel] [RFC PATCH] generalize QOM path resolution

[Paolo Bonzini]

On 01/30/2012 02:39 PM, Anthony Liguori wrote:
> On 01/30/2012 06:53 AM, Paolo Bonzini wrote:
> > Right now, resolving a string to an object is not generic to QOM,
> > but rather it is entirely embedded in qdev (the Device class).
> > This embryo patch generalizes the concept adding a resolve_path
> > class method, and get_canonical_path instance method, to Object.
>
> https://github.com/aliguori/qemu/commit/c354035aa4d2e30eb4d3864c5a7d8e9ef23a7deb
>
> This is in series 3/4 which I'm going to try to clean up enough to post
> today.

Yeah, there's many good things in there and we happen to disagree on 
this one. :)

> > Link properties use the type to direct sets to the right resolve_path
> > method, while the qom-{get,set,list} commands get a class argument.
> >
> > This is needed to have different namespaces for devices, host drives,
> > host chardevs, etc. and to make block/chardev/etc. properties be simply
> > links (after QOMification).
>
> I'm not sure I understand... There should be one global namespace and
> only one global namespace.
>
> We can maintain compatibility by giving each legacy command option it's
> own directory within the tree (just like we stick -device creations into
> /peripherial, -drive would have a /drive sub directory).

I think that you're giving too much weight to the "legacy" aspect.  We 
should try to design things so that (while keeping good taste overall) 
the legacy parts can be minimized asap and instead the QOM view of the 
world starts surfacing into the upper layers---including the 
command-line.  Striving for perfection means that we'll be stuck forever 
with large legacy pieces and no dogfooding for the cool bits.

One of the next things I want to do is to remove the legacy properties 
when the normal ones do exactly the same.  For property types that are 
using get_generic/set_generic we can basically change the upper layers 
to use get/set directly instead of parse/print.  Most of these cases, in 
turn, are going to become link properties to block devices or character 
devices.  Here are two things I absolutely would like to avoid:

1) having the legacy aspect disappear for now, only to reappear after 
block or character devices are converted to QOM;

2) having to introduce legacy properties whose QOM counterpart is a link.

Once we have QOMified enough that a property can be a link, you should 
be able to drop its legacy counterpart.

I see your point about having a single global namespace, but shoehorning 
entirely different branches of the tree into the same namespace 
introduces gratuitous incompatibilities between the qdev and the QOM 
views of the world.  And these are bad, because they limit the amount of 
QOM dogfooding that we can do inside QEMU itself.

You are not going to have anyway a link<Object>.  That makes it fine to 
resolve a link<Block> and a link<Device> according to different rules.

> We provide 100% ABI compatibility with QOM. The rules to achieve that are:
>
> 1) Once a type name is used, it never has a different semantic meaning.
>
> 2) Once a property is added to a type, it never has different semantic
> meaning. It's QOM property type may change, provided that the types are
> Visitor-compatible.
>
> 3) Types can be removed and properties can be removed.

That sounds good.

Paolo