From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3OGI-0008Ba-Ev for qemu-devel@nongnu.org; Sun, 28 Jul 2013 06:31:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3OG9-0003tG-LN for qemu-devel@nongnu.org; Sun, 28 Jul 2013 06:31:38 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57718 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3OG9-0003t6-DF for qemu-devel@nongnu.org; Sun, 28 Jul 2013 06:31:29 -0400 Message-ID: <51F4F2FB.5010800@suse.de> Date: Sun, 28 Jul 2013 12:31:23 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1374681580-17439-1-git-send-email-mst@redhat.com> <1374681580-17439-12-git-send-email-mst@redhat.com> <20130725093248.GA27524@redhat.com> <51F46201.2010106@suse.de> <20130728073028.GF12087@redhat.com> <51F4E689.80405@suse.de> <20130728101427.GA15065@redhat.com> In-Reply-To: <20130728101427.GA15065@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 11/14] piix: APIs for pc guest info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , qemu-devel@nongnu.org, Aurelien Jarno , Gerd Hoffmann Am 28.07.2013 12:14, schrieb Michael S. Tsirkin: > On Sun, Jul 28, 2013 at 11:38:17AM +0200, Andreas F=E4rber wrote: >> Am 28.07.2013 09:30, schrieb Michael S. Tsirkin: >>> On Sun, Jul 28, 2013 at 02:12:49AM +0200, Andreas F=E4rber wrote: >>>> Am 25.07.2013 11:32, schrieb Michael S. Tsirkin: >>>>> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c >>>>> index 3908860..daefdfb 100644 >>>>> --- a/hw/pci-host/piix.c >>>>> +++ b/hw/pci-host/piix.c >>>>> @@ -349,6 +349,14 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_s= tate, int *piix3_devfn, >>>>> return b; >>>>> } >>>>> =20 >>>>> +PCIBus *find_i440fx(void) >>>>> +{ >>>>> + PCIHostState *s =3D OBJECT_CHECK(PCIHostState, >>>>> + object_resolve_path("/machine/i= 440fx", NULL), >>>>> + TYPE_PCI_HOST_BRIDGE); >>>> >>>> Open-coded OBJECT_CHECK() - should use existing PCI_HOST_BRIDGE(...)= . >>>> >>>>> + return s ? s->bus : NULL; >>>>> +} >>>> >>>> Is this function really necessary? /machine/i440fx/pci.0 is a trivia= l >>>> addition to the path that's already being used here. You can do: >>>> PCIBus *bus =3D PCI_BUS(object_resolve_path("/machine/i440fx/pci.0")= ); >>>> where you actually need to access it. >>> >>> >>> I don't mind but I would like to avoid callers hard-coding >>> paths, in this case "i440fx". >>> Why the aversion to functions? >> >> Simply because QMP cannot call functions. It has to work with qom-list >> and qom-get, so this is a test case showing what is missing and can IM= O >> easily be addressed for both parties. >=20 > Fine but if the function calls QOM things internally > then where's the problem? The grief with object_path_resolve_type() is that it's a "hack" Paolo has added for his convenience (in audio code?) that QMP cannot use, so we need name-based paths to be available. And to clarify, I have been talking about two different time frames: Small adjustments that you can make for 1.6 (e.g., casts, q35 property, different QOM function/callsite used; if Anthony is okay with taking ACPI at this late point) and post-1.6 cleanups to replace interim constructs that involve refactorings outside your control (e.g., MemoryRegion QOM'ification, adding properties to random devices). Andreas >> The suggested cast to PCI_BUS() lets you use regular qdev functions bt= w >> as a shortcut, QMP users would need to iterate children of that node. >> >> The suggested "pci.0" is considered stable for -device ...,bus=3Dpci.0 >> according to review feedback the Xen people have received for libxl. --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg