| Message ID | 1402505369-12526-4-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Jun 12, 2014 at 2:49 AM, Paolo Bonzini <pbonzini@redhat.com> wrote: > An object must have a single parent, so creating an alias of > a child<> property breaks assumptions about objects having > a single canonical path. Fix this problem by turning these > aliases into links. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > qom/object.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/qom/object.c b/qom/object.c > index e146ae5..ddf781e 100644 > --- a/qom/object.c > +++ b/qom/object.c > @@ -1575,22 +1575,31 @@ void object_property_add_alias(Object *obj, const char *name, > { > AliasProperty *prop; > ObjectProperty *target_prop; > + gchar *prop_type; > > target_prop = object_property_find(target_obj, target_name, errp); > if (!target_prop) { > return; > } > > + if (object_property_is_child(target_prop)) { > + prop_type = g_strdup_printf("link%s", target_prop->type + 5); strlen("child") ? Or some comment to explain the magic 5. Otherwise: Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Longer term, should "child" and "link" be macrofied and these hardcoded strlen's be fixed to avoid difficult developer traps if anyone ever tries to change the literal strings? Regards, Peter > + } else { > + prop_type = g_strdup(target_prop->type); > + } > + > prop = g_malloc(sizeof(*prop)); > prop->target_obj = target_obj; > prop->target_name = target_name; > > - object_property_add_full(obj, name, target_prop->type, > + object_property_add_full(obj, name, prop_type, > property_get_alias, > property_set_alias, > property_resolve_alias, > property_release_alias, > prop, errp); > + > + g_free(prop_type); > } > > static void object_instance_init(Object *obj) > -- > 1.8.3.1 > > >
Il 17/06/2014 15:28, Peter Crosthwaite ha scritto: > > Longer term, should "child" and "link" be macrofied and these > hardcoded strlen's be fixed to avoid difficult developer traps if > anyone ever tries to change the literal strings? Yes, good idea. Paolo
Am 17.06.2014 15:31, schrieb Paolo Bonzini: > Il 17/06/2014 15:28, Peter Crosthwaite ha scritto: >> >> Longer term, should "child" and "link" be macrofied and these >> hardcoded strlen's be fixed to avoid difficult developer traps if >> anyone ever tries to change the literal strings? > > Yes, good idea. We do have static inline functions for that somewhere, probably in object.c. We could move them to the header if needed elsewhere. Andreas
Am 17.06.2014 15:28, schrieb Peter Crosthwaite: > On Thu, Jun 12, 2014 at 2:49 AM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> diff --git a/qom/object.c b/qom/object.c >> index e146ae5..ddf781e 100644 >> --- a/qom/object.c >> +++ b/qom/object.c >> @@ -1575,22 +1575,31 @@ void object_property_add_alias(Object *obj, const char *name, >> { >> AliasProperty *prop; >> ObjectProperty *target_prop; >> + gchar *prop_type; >> >> target_prop = object_property_find(target_obj, target_name, errp); >> if (!target_prop) { >> return; >> } >> >> + if (object_property_is_child(target_prop)) { >> + prop_type = g_strdup_printf("link%s", target_prop->type + 5); > > strlen("child") ? +1 > Or some comment to explain the magic 5. > > Otherwise: > > Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> > > Longer term, should "child" and "link" be macrofied and these > hardcoded strlen's be fixed to avoid difficult developer traps if > anyone ever tries to change the literal strings? I think my preference would be a helper function that returns the T from link<T> (non-dup'ed), which could then here be used as "link<%s>". The issue with a constant is that elsewhere 6 would be used. Regards, Andreas
Il 17/06/2014 18:37, Andreas Färber ha scritto: >> > >> > Longer term, should "child" and "link" be macrofied and these >> > hardcoded strlen's be fixed to avoid difficult developer traps if >> > anyone ever tries to change the literal strings? > I think my preference would be a helper function that returns the T from > link<T> (non-dup'ed), which could then here be used as "link<%s>". How can you return it non-dup'ed? The trailing > gets in the way. For now I just used strlen("child"). Paolo
Am 17.06.2014 18:46, schrieb Paolo Bonzini: > Il 17/06/2014 18:37, Andreas Färber ha scritto: >>> > >>> > Longer term, should "child" and "link" be macrofied and these >>> > hardcoded strlen's be fixed to avoid difficult developer traps if >>> > anyone ever tries to change the literal strings? >> I think my preference would be a helper function that returns the T from >> link<T> (non-dup'ed), which could then here be used as "link<%s>". > > How can you return it non-dup'ed? The trailing > gets in the way. Crap, didn't think of >. > For now I just used strlen("child"). Works for me. Andreas
diff --git a/qom/object.c b/qom/object.c index e146ae5..ddf781e 100644 --- a/qom/object.c +++ b/qom/object.c @@ -1575,22 +1575,31 @@ void object_property_add_alias(Object *obj, const char *name, { AliasProperty *prop; ObjectProperty *target_prop; + gchar *prop_type; target_prop = object_property_find(target_obj, target_name, errp); if (!target_prop) { return; } + if (object_property_is_child(target_prop)) { + prop_type = g_strdup_printf("link%s", target_prop->type + 5); + } else { + prop_type = g_strdup(target_prop->type); + } + prop = g_malloc(sizeof(*prop)); prop->target_obj = target_obj; prop->target_name = target_name; - object_property_add_full(obj, name, target_prop->type, + object_property_add_full(obj, name, prop_type, property_get_alias, property_set_alias, property_resolve_alias, property_release_alias, prop, errp); + + g_free(prop_type); } static void object_instance_init(Object *obj)
An object must have a single parent, so creating an alias of a child<> property breaks assumptions about objects having a single canonical path. Fix this problem by turning these aliases into links. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- qom/object.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)