From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEOoR-0006kl-FC for qemu-devel@nongnu.org; Wed, 10 Jun 2009 10:29:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEOoM-0006gy-Je for qemu-devel@nongnu.org; Wed, 10 Jun 2009 10:29:58 -0400 Received: from [199.232.76.173] (port=54977 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEOoM-0006gt-BN for qemu-devel@nongnu.org; Wed, 10 Jun 2009 10:29:54 -0400 Received: from mx20.gnu.org ([199.232.41.8]:57753) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MEOoM-0005Ef-10 for qemu-devel@nongnu.org; Wed, 10 Jun 2009 10:29:54 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MEOoK-00021R-Vm for qemu-devel@nongnu.org; Wed, 10 Jun 2009 10:29:53 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 1/3] qdev-ify isa pic Date: Wed, 10 Jun 2009 15:29:48 +0100 References: <1244545261-23679-1-git-send-email-kraxel@redhat.com> <5b31733c0906100243q13ef6181h160b7e88c2106194@mail.gmail.com> <4A2F81DA.4070108@redhat.com> In-Reply-To: <4A2F81DA.4070108@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101529.49244.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Filip Navara , Gerd Hoffmann On Wednesday 10 June 2009, Gerd Hoffmann wrote: > On 06/10/09 11:43, Filip Navara wrote: > > On Wed, Jun 10, 2009 at 9:32 AM, Gerd Hoffmann wrote: > > [snip]> > > > >> In general I think we should handle as much as possible at DeviceState / > >> DeviceInfo level. Stuff which devices commonly have should live there: > >> IRQs, mmio, ioports, ... in DeviceState. name, init and other generic > >> callbacks, ... in DeviceInfo. > >> > >> The bus structs should only hold stuff which is actually specific to > >> that bus. That is probably almost nothing for sysbus. i2c has the xfer > >> callbacks in I2CSlaveInfo. Likewise pci can have the config space > >> read/write callbacks in PCIDeviceInfo. > > > > This is definitely based on wrong assumptions. I've GPIO devices > > modelled on top of qdev and they don't know anything about IRQs, MMIO > > or stuff like that. All they know about is that there are few in/out > > GPIO pins, which are connected to the GPIO controller in the emulated > > microcontroller. > > Sure, not every device has IRQs. Nevertheless almost every bus out > there supports IRQs. Thus it is IMHO pointless to have a common thing > duplicated in each end every bus implementation, it should be in the > most basic type instead. My initial implementation tried to push IRQ and MMIO handling into DeviceState, and it didn't fit well. PCI v.s. SysBus is a good example here. Both have IRQs and MMIO regions. However the way these are configured and exposed to devices is very different. In practice you end up needing per-bus wrappers/hooks, and there's very little useful common code. For things that are truly bus agnostic (or independent of the primary bus, e.g. GPIO pins) pushing up to the qdev level makes sense. Paul