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

[Blue Swirl <blauwirbel@gmail.com>]

On 5/5/09, Paul Brook <paul@codesourcery.com> wrote:
> The attached patch is my attempt at a new internal API for device creation in
>  qemu.
>
>  The long term goal here is fully dynamic machine construction, i.e. a user
>  supplied configuration file/tree rather than the current hardcoded board
>  configs.
>
>  As a first step towards this, I've implemented an API that allows devices to
>  be created and configured without requiring device specific knowledge.
>
>  There are two sides to this API.  The device side allows a device to
>  register/configure functionality (e.g. MMIO regions, IRQs, character devices,
>  etc). Most of the infrastructure for this is already present, we just need to
>  configure it consistently, rather than on an ad-hoc basis. I expect this API
>  to remain largely unchanged[1].
>
>  The board side allows creation on configuration of devices. In the medium term
>  I expect this to go away, and be replaced by data driven configuration.
>
>  I also expect that this device abstraction will let itself to a system bus
>  model to solve many of the IOMMU/DMA/address mapping issues that qemu
>  currently can't handle.
>
>  There are still a few rough edges. Busses aren't handled in a particularly
>  consistent way, PCI isn't particularly well integrated, and the
>  implementation of things like qdev_get_chardev is an ugly hack mapping onto
>  current commandline options. However I believe the device side API is fairly
>  solid, and is a necessary prerequisite for fixing the bigger configuration
>  problem.
>
>  I've converted a bunch of devices, anyone interested in seeing how it fits
>  together in practice can pull from
>   git://repo.or.cz/qemu/pbrook.git qdev
>
>  It you have objections to or suggestion about this approach please speak up
>  now, but please bear in ming that this code is still somewhat in flux and the
>  caveats mentioned above.

FSF address is old.

About "int" property, I'd use a wider type to support 64 bit properties.

I don't think the ptr property can be used to construct OpenFirmware
properties, because the length of the data is not handled.

What happens if you try to register two devices of the same type, can
you identify them somehow? In OF, this is handed with by adding @ and
address.