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

[Anthony Liguori]

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.

> 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).

>  That's distant, but we should get it
> right before assumptions about global pathnames to pervade the code.
>
> The patch is not even compiled, and absolutely not in shape for getting
> in (but really, the only major hurdle for it is really Anthony's part 3
> and pushing properties up in the hierarchy).  The usual questions about
> this being the right thing to do already apply though.  And also: should
> QOM class names be part of the ABI/API?

The view I have re: QOM ABI/API:

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.

With respect to backwards compatibility, I don't think we should support 
backwards compatibility in QOM across minor releases (1.1 -> 1.2, etc.) but only 
within stable releases (1.1.1 -> 1.1.2).

For an application like libvirt, this should be fine because QOM exposes enough 
information about it's features that libvirt can just probe for various 
interfaces (it doesn't have to make decisions based on version numbers).

> Signed-off-by: Paolo Bonzini<address@hidden>
> ---
>   hw/qdev.c             |   34 +++++++++++++++++++++++++---------
>   include/qemu/object.h |    7 +++++++
>   qapi-schema.json      |    6 +++---
>   qmp.c                 |   26 ++++++++++++++++++++++----
>   qom/object.c          |   15 +++++++++++++++
>   roms/SLOF             |    2 +-
>   roms/seabios          |    2 +-
>   7 files changed, 74 insertions(+), 18 deletions(-)
>
> diff --git a/hw/qdev.c b/hw/qdev.c
> index a8c24de..1b8c1cd 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -43,6 +43,8 @@ DeviceInfo *device_info_list;
>   static BusState *qbus_find_recursive(BusState *bus, const char *name,
>                                        const BusInfo *info);
>   static BusState *qbus_find(const char *path);
> +static Object *device_resolve_path(const char *path, bool *ambiguous);
> +static gchar *device_get_canonical_path(Object *obj);
>
>   /* Register a new device type.  */
>   static void qdev_subclass_init(ObjectClass *klass, void *data)
> @@ -51,6 +53,8 @@ static void qdev_subclass_init(ObjectClass *klass, void *data)
>
>       dc->info = data;
>       dc->reset = dc->info->reset;
> +    dc->parent_class.resolve_path = device_resolve_path;
> +    dc->parent_class.get_canonical_path = device_get_canonical_path;

I definitely don't want to have multiple object graphs.  The object graph should 
reflect the real relationships between objects in QEMU.

Regards,

Anthony Liguori