From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZiGr-0000X7-I3 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:30:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZiGo-0002wL-QT for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:30:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:36106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZiGo-0002wB-G5 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 12:30:50 -0400 References: <87io7j7j4y.fsf@blackfin.pond.sub.org> <55F0462D.8080709@suse.de> <87d1xr62ji.fsf@blackfin.pond.sub.org> <55F0587A.1070301@suse.de> <55F05B4C.9080708@redhat.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <55F05EB9.7040606@suse.de> Date: Wed, 9 Sep 2015 18:30:49 +0200 MIME-Version: 1.0 In-Reply-To: <55F05B4C.9080708@redhat.com> 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: Paolo Bonzini , Markus Armbruster Cc: qemu-devel@nongnu.org, Luiz Capitulino Am 09.09.2015 um 18:16 schrieb Paolo Bonzini: > On 09/09/2015 18:04, Andreas F=C3=A4rber wrote: >>>> Should qom-list really fail DeviceNotFound? I find it rather confus= ing. >>>> For what it's worth, attempting to read a directory fails with EISDI= R, >>>> not ENOENT. >> Listing a non-existing directory on my system results in: >> >> ls: cannot access foo: No such file or directory >=20 > This is more like >=20 > $ ls vl.c/* > ls: cannot access vl.c/*: Not a directory >=20 > So it's ENOTDIR. Not really DeviceNotFound, but perhaps close enough. >=20 > FWIW, "struct" isn't a well-defined QAPI name. The type probably shoul= d > be changed to "any" (right?). If you guys want to change either, just discuss among yourselves and post a patch. I couldn't care less... fdt does not resolve as an object, so any error message optimizations would just add unnecessary complexity - unless I'm missing something. (parsing the path, checking whether the parent object does resolve, checking whether a property of the same name exists on that object) Due to the QMP vs. HMP mess, two callsites may be affected. The choice of type is done at the callsite, not in QOM code, so I'm even more the wrong one to complain to. -> ppc maintainers? 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)