Hi, >>> Yes I agree. Creating a now QOM definition for every variant of a >>> device is tedious. EHCI provides a nice abstraction which should not >>> have awareness of its particular implementations. >> >> Maybe "zynq" is the wrong abstraction and this should be named by the >> actual ehci chip implementation (which could be the same for a bunch of >> sysbus boards). >> >> But, yes, different chips should have different QOM definitions. Like >> we have a bunch of different uhci variants with a QOM definition for >> each of them. > > Can we at least take a data driven approach to this?
Ahem. Well. I'd love to. It even used to be that way, before QOM. uhci had a simple PCIDeviceInfo table, with an entry for each variant. QOM turned that a bunch of class_init functions ... Looking a bit closer (at include/qemu/object.h): seems we can pass additional data to TypeInfo->class_init via TypeInfo->class_data. That should help here. I'll go try that to simplify uhci ... cheers, Gerd
