On 02/09/2011 02:01 AM, Markus Armbruster wrote:
Anthony Liguori<anthony@xxxxxxxxxxxxx> writes:
On 02/08/2011 11:13 AM, Markus Armbruster wrote:
Chris Wright<chrisw@xxxxxxxxxx> writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific ideas welcome. Patches even more, as
always.
I think we need to improve the i440fx modelling as a lot of the stuff
done in the machine init for pc really belongs as part of the i440fx.
In theory, creating an i440fx ought to be essentially equivalent to
the machine init function today.
* Convert the remaining devices. They are typically used only with
oddball machines, which makes the conversion hard to test for anyone
who's not already using them.
I've said this before: at some point in time (sooner rather than
later, if you ask me), we need to shoot the stragglers. I'm pretty
optimistic that any victims worth keeping will receive timely
attention then.
Anything else?
We need to unify the property model. We have QemuOpts, qdev
properties, and QObject which basically reinvents variant typing three
different ways.
Make it four: QEMUOptionParameter.
Now let me make it three again. Unlike the others, a qdev property
describes a perfectly ordinary, non-variant struct member. It's poor
man's reflection, not a variant type.
Except that construction of a device requires initialization from an
array of variants (which is then type checked). The way we store the
variants is lossy because we convert back and forth to a string.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
