From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MEIL1-00022B-L6
	for qemu-devel@nongnu.org; Wed, 10 Jun 2009 03:35:11 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MEIKw-00021z-6d
	for qemu-devel@nongnu.org; Wed, 10 Jun 2009 03:35:10 -0400
Received: from [199.232.76.173] (port=51836 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MEIKw-00021w-4L
	for qemu-devel@nongnu.org; Wed, 10 Jun 2009 03:35:06 -0400
Received: from mx2.redhat.com ([66.187.237.31]:45119)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MEIKv-0001jm-Ke
	for qemu-devel@nongnu.org; Wed, 10 Jun 2009 03:35:05 -0400
Message-ID: <4A2F61AA.3020502@redhat.com>
Date: Wed, 10 Jun 2009 09:32:58 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/3] qdev-ify isa pic
References: <1244545261-23679-1-git-send-email-kraxel@redhat.com>
	<200906091632.19195.paul@codesourcery.com>
	<4A2E84F8.7020303@redhat.com>
	<200906091658.15889.paul@codesourcery.com>
In-Reply-To: <200906091658.15889.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

On 06/09/09 17:58, Paul Brook wrote:

>> Why doesn't sysbus_init_irq() call qdev_init_gpio_out()?
>
> Because some devices have both IRQs and GPIO outputs.

What is the point of this commit here ...

http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=067a3ddc8876cee8451d6f690a051e413a593fdc

then?

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.

With more and more stuff coming to DeviceInfo it probably becomes more 
useful to have the device register functions just pass a DeviceInfo 
struct (or a bus-specific one like PCIDeviceInfo with DeviceInfo as 
element) to the register function, otherwise we'll end up with an 
ever-growing list of arguments ...

cheers,
   Gerd