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

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/30/2012 08:03 AM, Paolo Bonzini wrote:
> 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.

I think we agreed (in IRC) that we can handle this by changing 
qdev_resolve_path() to take an optional TYPE argument which will cause 
qdev_resolve_path() to only succeed if the resulting object implements TYPE.

This can be used to disambiguate partial path matches such that a 
link<BlockDriverState> property would only attempt to do partial path 
resolutions on objects that have BlockDriverState in their parent hierarchy.

Regards,

Anthony Liguori