From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZi2m-0000wY-21 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:16:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZi2i-0004i6-Lu for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:16:19 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:35515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZi2i-0004gl-Cv for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:16:16 -0400 Received: by wicge5 with SMTP id ge5so161573903wic.0 for ; Wed, 09 Sep 2015 09:16:15 -0700 (PDT) Sender: Paolo Bonzini References: <87io7j7j4y.fsf@blackfin.pond.sub.org> <55F0462D.8080709@suse.de> <87d1xr62ji.fsf@blackfin.pond.sub.org> <55F0587A.1070301@suse.de> From: Paolo Bonzini Message-ID: <55F05B4C.9080708@redhat.com> Date: Wed, 9 Sep 2015 18:16:12 +0200 MIME-Version: 1.0 In-Reply-To: <55F0587A.1070301@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Markus Armbruster Cc: qemu-devel@nongnu.org, Luiz Capitulino 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