qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>,
	"Markus Armbruster" <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-connector[255]/fdt
Date: Wed, 9 Sep 2015 18:16:12 +0200	[thread overview]
Message-ID: <55F05B4C.9080708@redhat.com> (raw)
In-Reply-To: <55F0587A.1070301@suse.de>



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

  reply	other threads:[~2015-09-09 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09 14:38 [Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-connector[255]/fdt Markus Armbruster
2015-09-09 14:46 ` Andreas Färber
2015-09-09 15:22   ` Markus Armbruster
2015-09-09 16:04     ` Andreas Färber
2015-09-09 16:16       ` Paolo Bonzini [this message]
2015-09-09 16:30         ` Andreas Färber
2015-09-13  2:04         ` Eric Blake
2015-09-10  8:55       ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55F05B4C.9080708@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).