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.