On 12/13/2011 03:48 AM, Gerd Hoffmann wrote:
Hi,
Now I understand that for dynamically created properties (like on your
PCB) this is necessary and can't be avoided. For about 99% of the
devices static definition of properties would be enough, though.
So basically what I'm asking for is getting the static structs back for
the 99% and have common code that parses them and calls the appropriate
functions to actually the properties. The remaining 1% that
creates/deletes properties during runtime and isn't covered can directly
call whatever it needs.
Fully agree. I guess we can even generate those structs in many cases.
We will parse the ${device}State structs anyway for visitor-based
vmstate, so with some extra declaration we can generate property
descriptions too. For example this ...
static PCIDeviceInfo intel_hda_info = {
.qdev.name = "intel-hda",
[ ... ]
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
DEFINE_PROP_END_OF_LIST(),
}
};
... could be just ...
struct IntelHDAState {
[ ... ]
/* properties */
uint32_t debug __property(0);
uint32_t msi __property(1);
};
Yup, that's where I want to go. In qom-next, I've started splitting header
files out specifically so we can do stuff like this. There's quite a bit of
work to do before we can really start exploring here but I think it's not that
much work to get the pc device models cleaned up such that we could run qc
against the headers.
Regards,
Anthony Liguori
cheers,
Gerd
