qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Wed, 09 Feb 2011 20:53:48 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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.





reply via email to

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