Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/09/2011 06:48 PM, Blue Swirl wrote:
>
>> We can just do:
>>
>> ISASerialState dev;
>>
>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>      
> Do you mean that there should be a generic way of doing that, like
> sysbus_create_varargs() for qdev, or just add inline functions which
> hide qdev property setup?
>    

qdev properties are construct-only right now.

What qdev is trying to do is provide a mechanism invoke constructors 
through a factory interface where the inputs can come from many places.

Another way of doing this is to just have a normal constructor like:

void isa_serial_init(ISASerialState *dev, uint32_t iobase, ...)
{
      dev->iobase = iobase;
}

And then have an (autogenerated) factory proxy:

static ISASerialState *isa_serial_factory(QemuOpts *opts)
{
      ISASerialState *isa = qemu_mallocz(sizeof(*isa));
      isa_serial_init(isa, qemu_opt_get_int(opts, "iobase"), ...);
      return isa;
}

The advantage of this model is that you can have multiple factory 
interfaces to create a device.  For instance, you can have a QemuOpts 
based factory for -device and a QDict based factory for QMP.

In addition, normal C code doesn't have to deal with any of the factory 
interfaces.  It can just invoke a normal C interface.

Building the factory interface as an intrinsic part of qdev was a 
mistake IMHO.

Regards,

Anthony Liguori

> I still think that FDT should be used in the future. That would
> require that the properties can be set up mechanically, and I don't
> see how your proposal would help that.
>
>