From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgJdb-0004PT-9h for qemu-devel@nongnu.org; Mon, 11 Jul 2011 12:47:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgJdZ-0000u8-FG for qemu-devel@nongnu.org; Mon, 11 Jul 2011 12:47:15 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:48415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgJdY-0000tD-W0 for qemu-devel@nongnu.org; Mon, 11 Jul 2011 12:47:13 -0400 Received: by mail-pz0-f45.google.com with SMTP id 30so4082848pzk.4 for ; Mon, 11 Jul 2011 09:47:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E1B16D7.9020802@redhat.com> References: <4E1AF12D.7070407@redhat.com> <4E1B16D7.9020802@redhat.com> Date: Mon, 11 Jul 2011 17:47:12 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] qdev for programmers writeup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 11 July 2011 16:29, Paolo Bonzini wrote: > On 07/11/2011 04:44 PM, Peter Maydell wrote: >> (Also if you have one bus type >> per board then you're still very limited in what you can do with -device >> because you can't plug in some random other sysbus device anyway.) > > I'm not talking about one bus type per board! =C2=A0I'm talking about as = few as > possible board-specific root devices, and sharing buses between boards as > much as possible. Er, doesn't that just get you sysbus again? Also if you have a root device and it's not the CPU then something's a bit odd. (The CPU lives above the interrupt controller in the interrupt tree if you want to look at it like that.) >> So if >> we want to allow runtime configurability of boards like that we need >> to do it by providing runtime configurability of sysbus devices. > > But we already have properties as a runtime configurability mechanism, an= d > the additional functionality provided by SysBus is exactly to bypass it. = =C2=A0In > that sense SysBus is bad (if used widely as it is now). > > It is also bad because SysBus takes device metainformation (number of IRQ > lines, size of MMIO and PIO areas) and puts it into per-device structure. I think the real reason so many devices use sysbus is that it is basically "I'm a device and I support some gpio signals and some memory mappings", which is just a very natural way to model a lot of things. It's also an easy to use API for machine models to instantiate and wire up both IRQs and memory mappings. If we want less use of sysbus then we need to have the basic qdev device model have much better support for doing this. >> I think it would be better to think of GPIO as a special (simple) >> case of a generic desire to plug devices into each other (this is what >> SystemC calls a "port": basically an interface (API) defined so that >> two things can make calls to arbitrary callback functions on the other >> end of a connection). How ports are wired up is a property of the >> machine model, not a property of the device at either end > > But in practice you tend to have tree-like relationships. =C2=A0Even if i= t is > just a two-level tree with a GPIO chip or interrupt controller at one end= , > and everything else at the other. Yes, but the tree-like relation of the memory transaction bus/interconnect isn't necessarily the same as the tree-like relation of the interrupt controllers; and the tree-like relation of the clocks might be different again. And even if things tend to be tree-like, you still need to support arbitrary inter-wiring for the corner cases (like "this MMC controller's 'card present' wire needs to connect to the board-register model's input"). You can model trees with arbitrary interconnections, but not vice-versa. Insisting that interrupts are always a tree also rules out ever having qemu support multiple distinct CPUs where some interrupt sources end up going to more than one CPU; I'd rather we didn't bake that kind of assumption into the core device model if possible. (This view of the world, which I accept is not really qdev's, says that a bus is really just a conveniently named and manipulable bundle of connections.) -- PMM