Hi,
Am 27.05.2013 09:50, schrieb Peter Crosthwaite:
> I have a bit of a chicken and egg problem trying to refactor Jans AT24
> I2C EEPROM model. I'm trying to migrate static class properties up to
> the class level rather than down on the device property level (as we
> did for EHCI in the sysbusification a while back). Problem is the
> device model has part autodetection logic based on the size of the
> backing image - you can instantiate the "abstract" class and selection
> of what part it is depends on the backing file size. And so if we go
> for one class for each separate part, we don't actually know what
> concrete class to instantiate until we have a handle on the bdrv at
> realize time which is way to late. Any Ideas?
I think the practical question to ask is: What's the difference between
those subclasses? Then maybe you can initialize YourAutoType::field from
DerivedTypeClass::template_field or the like. I.e., the class is
supposed to exist only once, so you can't modify it beyond class_init,
but you can modify the instance including field values and per-instance
callback hooks.
For a vaguely related example, you may want to look at the history of
target-ppc/kvm.c for how I previously mutated the host-ppc-cpu type -
depending on the host, not user parameters (today it uses inheritance
from a dynamically chosen base type instead; reason was not a technical
one but that target-ppc/kvm.c does not get compile-tested on x86 if
someone changes/adds ppc-cpu fields - no concern for regular devices).
FWIW bdrv not fitting well into the realize scheme was the main reason
behind going for DeviceState rather than Object for realize. ;)
BTW do we have any guidance of when to use properties vs. subclasses?
Might be a good addition to the QOMConventions page since it recently
came up for CAN as well.
> Can you safely change a devices type at realize time?
>
> realize() {
> ...
> OBJECT(dev)->class = the_now_known_correct_child_class;
> ...
> }
>
> Obviously this would need an API call in QOM to sanity check it.
Short answer: No, such a mutation is generally unsafe.
Instance sizes can differ between types - could be sanity-checked.
A type can expect to get access to its final class on instance_init.
instance_init may init fields that you can only get by instantiating.
A type mutation would change child<> or link<> properties at runtime.
Realize will be too late to tweak the resulting instance further.
Real OO languages don't support it, causing QOM lock-in.
So I think this is rather hinting into the direction of a three-stage
construction - instance_init, open, realize - as discussed by
Kevin/Markus some time ago.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
