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

Anthony Liguori
2011-02-09T19:54:06Z

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