From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmBjT-0003JG-3z for qemu-devel@nongnu.org; Wed, 27 Jul 2011 17:33:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmBjN-00053F-Fi for qemu-devel@nongnu.org; Wed, 27 Jul 2011 17:33:34 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:45987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmBjN-00052v-Cg for qemu-devel@nongnu.org; Wed, 27 Jul 2011 17:33:29 -0400 Received: by gxk26 with SMTP id 26so1661813gxk.4 for ; Wed, 27 Jul 2011 14:33:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E2EC90E.8090409@codemonkey.ws> References: <1311558293-5855-1-git-send-email-aliguori@us.ibm.com> <4E2EBA1E.90006@redhat.com> <4E2EC90E.8090409@codemonkey.ws> Date: Wed, 27 Jul 2011 22:33:27 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org On 26 July 2011 15:02, Anthony Liguori wrote: > In my attempt at PCI modelling, I had something like: > > struct I440FX > { > =C2=A0 Device parent; > > =C2=A0 PciDevice slots[32]; > }; > > Which means that to attach to bus 0, slot 3, fn 0, you do: > > i440fx->slots[3] =3D mydevice So what I don't really understand about this model is why the PCI connection is "privileged" in the sense that 'mydevice' is actually an instance of something you can stick directly into one of the PCIBus device's slots. I would expect that 'mydevice' would have a bunch of (effectively) interfaces it exposed, and you'd connect i440fx->slots[3] to mydevice.pciconnector or something. [Which ought to both let the PCIBus call functions implemented by the device, and vice versa.] (What would a model of a two-PCI-slot graphics card look like?) Maybe it would be better to use some other example. After all, the cases like PCI are the ones our device model already handles pretty well, so the interesting cases to look at are where we're not so good at it. What does the implementation of omap2_gpio look like, for instance? (it's not qdev at the moment but there's a set of patches on the list which make it so; the guts of the qdevification are http://patchwork.ozlabs.org/patch/103905/ .) That's a device which exposes: * 4,5, or 6 MMIO regions (depending on how many 'modules' the particular revision you ask for has) * a variably sized array of gpio inputs * ditto, gpio outputs * for each 'module', three specific named outgoing gpio lines "mpu_irq", "dsp_irq" and "wakeup" * a number of omap_clk connections, where an omap_clk* represents a connection to the OMAP clock tree, and in practice is an interface where the omap_gpio can (a) call a function to ask "what rate is this clock running at?" and (b) provide a gpio line which will be raised when the clock ticks. [omap_gpio doesn't actually use its clock connections but other omap devices do; they're interesting because we have function calls going in both directions over the interface.] None of these exposed interfaces are particularly obviously more important than any of the others -- they're just all things that might need to be wired up. I'm particularly interested in how much effort is involved in defining ad-hoc platform-specific interface types like omap_clk. -- PMM