From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZhr7-0005NP-U1 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:04:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZhr1-0002vJ-P0 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:04:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:34518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZhr1-0002uz-G7 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:04:11 -0400 References: <87io7j7j4y.fsf@blackfin.pond.sub.org> <55F0462D.8080709@suse.de> <87d1xr62ji.fsf@blackfin.pond.sub.org> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <55F0587A.1070301@suse.de> Date: Wed, 9 Sep 2015 18:04:10 +0200 MIME-Version: 1.0 In-Reply-To: <87d1xr62ji.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-connector[255]/fdt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Luiz Capitulino Am 09.09.2015 um 17:22 schrieb Markus Armbruster: > Andreas F=C3=A4rber writes: >> Am 09.09.2015 um 16:38 schrieb Markus Armbruster: >>> I ran into this: >>> >>> $ qemu-system-ppc64 -nodefaults -S -display none -monitor stdio >>> -machine pseries-2.4 >>> QEMU 2.4.50 monitor - type 'help' for more information >>> (qemu) qom-list /machine/unattached/device[5]/dr-connector[255] >>> fdt (struct) >>> entity-sense (uint32) >>> name (string) >>> connector_type (uint32) >>> index (uint32) >>> id (uint32) >>> allocation-state (uint32) >>> indicator-state (uint32) >>> isolation-state (uint32) >>> parent_bus (link) >>> hotplugged (bool) >>> hotpluggable (bool) >>> realized (bool) >>> type (string) >>> (qemu) qom-list /machine/unattached/device[5]/dr-connector[255]/f= dt >>> Device '/machine/unattached/device[5]/dr-connector[255]/fdt' not = found >>> >>> According to the first qom-list, .../fdt exists. According to the >>> second, it doesn't. >> >> Actually this is fully expected: qom-list operates on QOM objects. The >> fdt property returns a struct, which is considered a value QOM-wise, s= o >> to read it you need to use qom-get, not qom-list. >> >> Now, it may well be that visiting a struct does not work as expected, = I >> remember we ran into issues there, that held up the qom-tree stuff... >=20 > Okay, switching to QMP, because there's no qom-get in HMP (is that > intentional?). >=20 > QMP> { "execute": "qom-list", "arguments": { "path": "/machine/unat= tached/device[5]/dr-connector[255]" } } > {"return": [{"name": "fdt", "type": "struct"}, {"name": "entity-sen= se", "type": "uint32"}, {"name": "name", "type": "string"}, {"name": "con= nector_type", "type": "uint32"}, {"name": "index", "type": "uint32"}, {"n= ame": "id", "type": "uint32"}, {"name": "allocation-state", "type": "uint= 32"}, {"name": "indicator-state", "type": "uint32"}, {"name": "isolation-= state", "type": "uint32"}, {"name": "parent_bus", "type": "link"}, {= "name": "hotplugged", "type": "bool"}, {"name": "hotpluggable", "type": "= bool"}, {"name": "realized", "type": "bool"}, {"name": "type", "type": "s= tring"}]} > QMP> { "execute": "qom-list", "arguments": { "path": "/machine/unat= tached/device[5]/dr-connector[255]/fdt" } } > {"error": {"class": "DeviceNotFound", "desc": "Device '/machine/una= ttached/device[5]/dr-connector[255]/fdt' not found"}} >=20 > 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 As for the DeviceNotFound, I merely implemented the HMP glue, so you should rather direct such questions at Eric or Luiz (or Anthony). I believe that an ObjectNotFound is out of the question, as any new code would just use the Generic class. >=20 > Moving on to my next confusion: qom-get. >=20 > QMP> { "execute": "qom-get", "arguments": { "path": "/machine/unatt= ached/device[5]/dr-connector[255]", "property": "fdt" } } > {"return": {}} >=20 > The return value {} is weird. Let's see where it comes from. >=20 > 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: >=20 > QObject *object_property_get_qobject(Object *obj, const char *name, > Error **errp) > { > QObject *ret =3D NULL; > Error *local_err =3D NULL; > QmpOutputVisitor *mo; >=20 > mo =3D qmp_output_visitor_new(); > object_property_get(obj, qmp_output_get_visitor(mo), name, &loc= al_err); >=20 > This call succeeds, and we enter the conditional. >=20 > if (!local_err) { > ret =3D qmp_output_get_qobject(mo); >=20 > This call returns NULL. >=20 > } > error_propagate(errp, local_err); >=20 > This sets *errp =3D NULL. >=20 > qmp_output_visitor_cleanup(mo); > return ret; > } >=20 > Function returns NULL without setting an error. Its function comment: >=20 > /* > * 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. > */ >=20 > Is returning NULL without setting an error okay? >=20 > Should it return qnull() instead? Then the QMP return value would be > JSON null. >=20 That smells like the StringOutputVisitor problem that was holding up HMP qom-get: http://patchwork.ozlabs.org/patch/449596/ IIRC I needed to add a test case - not sure if I did, and busy now. Searching for that subject should find you the qom-get patch as well. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N= =C3=BCrnberg)