From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgIQS-000117-J6 for qemu-devel@nongnu.org; Mon, 11 Jul 2011 11:29:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgIQQ-0004iT-FA for qemu-devel@nongnu.org; Mon, 11 Jul 2011 11:29:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgIQP-0004iO-VR for qemu-devel@nongnu.org; Mon, 11 Jul 2011 11:29:34 -0400 Message-ID: <4E1B16D7.9020802@redhat.com> Date: Mon, 11 Jul 2011 17:29:27 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4E1AF12D.7070407@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qdev for programmers writeup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On 07/11/2011 04:44 PM, Peter Maydell wrote: >> That's true, but the only way to plug in those device models would be with C >> code. You cannot just play with -device to reconfigure them. > > I think the C source level reuse is more important and more useful > than plugging stuff around with -device, because in practice messing > about with the memory map of an embedded board isn't something people > typically want to do, because the kernel will have more-or-less > hardcoded where the devices are anyhow. That's just because ARM doesn't (yet?) do device trees... :) > (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! I'm talking about as few as possible board-specific root devices, and sharing buses between boards as much as possible. > 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, and the additional functionality provided by SysBus is exactly to bypass it. In 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 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. Even if it is just a two-level tree with a GPIO chip or interrupt controller at one end, and everything else at the other. > Also, you want to be able to actually name your output pins, so > at a board level you can talk about wiring up sd_controller.wprot, > not sd_controller.gpio[3]... (Yes, this is to some extent "just syntax" > but I really don't want to end up with machine level modelling looking > like: It _is_ really just syntax. In my examples I used the raw values for GPIO pin numbers because that's what we have. So, right now there is no way to use symbolic values, but nothing forbids adding one. Or even automatically generating the QEMU .conf from something else. If you are using C code, of course you have #defines/enums. >> Well, it is clear that buses should be modelled after the way data flows. >> But what is data? If data is "what is being written", buses should be >> modelled after the way memory transactions flow. If data is "what is being >> made available", buses are modelled more "after the way interrupts flow. >> GPIO is a strange thing in the middle. :) > > Actually I think we should really be modelling buses only where the > hardware actually has a bus, ie a coherent collection of signals > between multiple devices such that you could in theory plug in > different devices in different slots. The memory transaction > related connections are much more buslike than interrupt wiring. I'm not sure, perhaps the naming is bad. Abstracting from the name for a moment, unifying interrupts/GPIO with the qbus concept seemed natural to me in most of the cases I looked at. And it makes the handling of GPIO in qdev less schizophrenic; qdev seems to treat the qbus (whatever it is) as the One True Mechanism to join devices, and then adds GPIO on the side while providing no way to configure it. If you try to match the qdev tree with the tree of qemu_irq, the design becomes a lot more coherent. Paolo