qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] New device API


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [RFC] New device API
Date: Wed, 6 May 2009 00:42:13 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

On Tue, May 05, 2009 at 01:22:45PM -0500, Anthony Liguori wrote:
> 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

Yes, I guess the memory access indirection will be useful once there is
better bus modeling. Another thing that could be useful is a generic
datapath between devices. For example to interconnect DMA controllers
with peripherals through side buses. 

These features can probably be added incrementally though.

Cheers

>
>
> 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
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]