From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M1PI8-0000M5-DV
	for qemu-devel@nongnu.org; Tue, 05 May 2009 14:22:56 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M1PI3-0000Jx-RZ
	for qemu-devel@nongnu.org; Tue, 05 May 2009 14:22:55 -0400
Received: from [199.232.76.173] (port=42203 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M1PI3-0000Jr-F2
	for qemu-devel@nongnu.org; Tue, 05 May 2009 14:22:51 -0400
Received: from an-out-0708.google.com ([209.85.132.250]:54680)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1M1PI2-000085-R8
	for qemu-devel@nongnu.org; Tue, 05 May 2009 14:22:51 -0400
Received: by an-out-0708.google.com with SMTP id d11so2714202and.37
	for <qemu-devel@nongnu.org>; Tue, 05 May 2009 11:22:48 -0700 (PDT)
Message-ID: <4A0083F5.7050606@codemonkey.ws>
Date: Tue, 05 May 2009 13:22:45 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] New device API
References: <200905051231.09759.paul@codesourcery.com>
In-Reply-To: <200905051231.09759.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-1; 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

Paul Brook wrote:
> The attached patch is my attempt at a new internal API for device creation in 
> qemu.
>   

Instead of recreating constructors, I think we should just use GCC's 
constructor attribute.  This gives us ordering which will be important 
when dealing with buses.

I think the layering is not quite right with qdev.

Not all devices fit into the parameters of register_mmio/connect_irq.  
When dealing with bus devices (like PCI devices), I think you really 
have to model the constructs that the bus expose.  Note, this starts to 
look very similar to the Linux kernel's layered device model.

For instance, the following makes sense to me (from an x86 perspective):

Device              <- for devices connected directly to the 
northbridge/southbridge
  - raise_interrupt(0..255)
  - lower_interrupt(0..255)
  - register_mmio
  - register_pio
  - read_memory
  - write_memory


A PCI controller is a Device, but it introduces the concept of 
PCIDevice.  This is:

PCIDevice
  - raise_link(A|B|C|D)
  - lower_link(A|B|C|D)
  - register_io_region(IO|MEM, BAR, size)
  - read_memory
  - write_memory

A SCSI controller is a PCIDevice, but it introduces the concept of 
SCSIDevice.  This is:

SCSIDevice
  - send_cdb()
  - recv_cdb()

And so forth.  Virtio is a bus, ISA is a bus, etc. etc.

Regards,

Anthony Liguori