Adding a layer of indirect calls is not very different from monkey patching
though.
I'm a little bothered by monkey patching, but I'm more
bothered by having to:
(1) register (module_init()) a function (kvm_cpu_accel_register()) that
(2) register (accel_register_call()) a function (kvm_cpu_accel_init()) that
(3) register (x86_cpu_accel_init()) a data structure (X86CPUAccel
kvm_cpu_accel) that
(4) will be saved in multiple QOM classes, so that
(5) we will call the right X86CPUClass.accel method at the right moment
(common_class_init(), instance_init(), realizefn()),
where:
step 4 must be done before any CPU object is created
(otherwise X86CPUAccel.instance_init & X86CPUAccel.realizefn
will be silently ignored), and
step 3 must be done after all QOM types were registered.
You also have to consider that accel currently does not exist in usermode
emulators, so that's an issue too. I would rather get a simple change in
quickly, instead of designing the perfect class hierarchy.
It doesn't have to be perfect. I agree that simple is better.
To me, registering a QOM type and looking it up when necessary is
simpler than the above. Even if it's a weird class having no
object instances. It probably could be an interface type.
Perhaps another idea would be to allow adding interfaces to classes
*separately from the registration of the types*. Then we can use it to add
SOFTMMU_ACCEL and I386_ACCEL interfaces to a bare bones accel class, and
add the accel object to usermode emulators.
I'm not sure I follow. What do you mean by bare bones accel
class, and when exactly would you add the new interfaces to the
classes?