Anthony Liguori <anthony@xxxxxxxxxxxxx> writes: > On 02/09/2011 02:01 AM, Markus Armbruster wrote: >> Anthony Liguori<anthony@xxxxxxxxxxxxx> writes: [...] >>> 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. Yes, there's overlap, but no, a qdev property isn't yet another variant type scheme. Exhibit A of the defense: qdev uses QemuOpts for variant types. Let me elaborate. qdev_device_add() uses QemuOpts as map from name to variant type value, uses the name to look up the property, then uses property methods to stuff the variant value it got from QemuOpts into the (non-variant) struct member described by the property. I figure QemuOpts was adopted for this purpose because it was already in use with command line and human monitor. With QMP added to the mix, there's friction: QMP uses QDict, not QemuOpts. -- 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
