[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-conne
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-connector[255]/fdt |
Date: |
Wed, 9 Sep 2015 18:16:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
On 09/09/2015 18:04, Andreas Färber wrote:
>> > Should qom-list really fail DeviceNotFound? I find it rather confusing.
>> > For what it's worth, attempting to read a directory fails with EISDIR,
>> > not ENOENT.
> Listing a non-existing directory on my system results in:
>
> ls: cannot access foo: No such file or directory
This is more like
$ ls vl.c/*
ls: cannot access vl.c/*: Not a directory
So it's ENOTDIR. Not really DeviceNotFound, but perhaps close enough.
FWIW, "struct" isn't a well-defined QAPI name. The type probably should
be changed to "any" (right?).
> > Moving on to my next confusion: qom-get.
> >
> > QMP> { "execute": "qom-get", "arguments": { "path":
> > "/machine/unattached/device[5]/dr-connector[255]", "property": "fdt" } }
> > {"return": {}}
> >
> > The return value {} is weird. Let's see where it comes from.
> >
> > qmp_qom_get() first calls object_resolve_path() on the path, then
> > object_property_get_qobject() on the property. For our test case,
> > object_resolve_path() succeeds. Now have a closer look at
> > object_property_get_qobject()'s behavior:
> >
> > QObject *object_property_get_qobject(Object *obj, const char *name,
> > Error **errp)
> > {
> > QObject *ret = NULL;
> > Error *local_err = NULL;
> > QmpOutputVisitor *mo;
> >
> > mo = qmp_output_visitor_new();
> > object_property_get(obj, qmp_output_get_visitor(mo), name,
> > &local_err);
> >
> > This call succeeds, and we enter the conditional.
> >
> > if (!local_err) {
> > ret = qmp_output_get_qobject(mo);
> >
> > This call returns NULL.
> >
> > Function returns NULL without setting an error. Its function comment:
> >
> > /*
> > * object_property_get_qobject:
> > * @obj: the object
> > * @name: the name of the property
> > * @errp: returns an error if this function fails
> > *
> > * Returns: the value of the property, converted to QObject, or NULL if
> > * an error occurs.
> > */
> >
> > Is returning NULL without setting an error okay?
> >
> > Should it return qnull() instead? Then the QMP return value would be
> > JSON null.
JSON null support in QObject is new, it should be the result of
object_property_get_qobject() or even qmp_output_get_qobject(). Needs
auditing the code.
Paolo