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
