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

[Paul Brook <paul@codesourcery.com>]

> > The attached patch is my attempt at a new internal API for device
> > creation in qemu.
>...
> I think the general direction is good, and this is sorely needed, but I
> think having a fixed / static device struct isn't flexible enough to
> handle the complexities of multiple device / bus types - for example,
> MSI-X could add tons of IRQ vectors to a device, or complex devices
> could have tons of MMIO regions.
>
> I think a more flexible scheme would be to have a common device header,
> and fixed substructures which are added as needed to a device.

I'm not sure how much benefit this gives in practice, or how much it's worth 
catering for the "same" device that can be attached to different busses. 
While e.g. both PCI and non-PCI devices have MMIO regions and IRQ sources, 
I'm not sure how much can be shared between the two. I suspect the common 
infrastructure extended as far as cpu_register_io_memory/qemu_irq (or 
equivalent), but using the same API for the bus/device interaction is more 
trouble then it's worth.

While a fancy multiple inheritance system like you describe is in interesting 
idea, It feels over-engineered for this particular problem.

> The config issue is certainly a very important problem to address.  I
> think it should be noted there are three types of configuration data,
> all of which are ontologically different.  There are:
>
> 1) Static per-device configuration choices, such as feature enable /
> disable, framebuffer size, PCI vs. ISA bus representation. 
>
> 2) Dynamic per-device data.  

I think these two largely fall out together. Once you've determined that 
you're dealing with a PCI device, all the associated dynamic PCI data follows 
directly from that.

> 3) Implementation specific data.  Pieces of data which are required for
> a particular realization of a device on the host, such as file
> descriptors, call back functions, authentication data, network routing.

We already have things like CharDevice and BlockDriverState to isolate devices 
from the host implementation. In the past this is the distinction I've made 
between user-level config and machine config.

Paul