On 08/06/2013 08:12 PM, Andreas Färber wrote: >> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h >> index 1066f69..e5889e9 100644 >> --- a/include/hw/ppc/xics.h >> +++ b/include/hw/ppc/xics.h >> @@ -35,6 +35,9 @@ >> #define TYPE_XICS "xics" >> #define XICS(obj) OBJECT_CHECK(XICSState, (obj), TYPE_XICS) >> >> +#define TYPE_KVM_XICS "xics-kvm" >> +#define KVM_XICS(obj) OBJECT_CHECK(KVMXICSState, (obj), TYPE_KVM_XICS) >> + >> #define XICS_COMMON_CLASS(klass) \ >> OBJECT_CLASS_CHECK(XICSStateClass, (klass), TYPE_XICS_COMMON) >> #define XICS_CLASS(klass) \ >> @@ -44,6 +47,9 @@ >> #define XICS_GET_CLASS(obj) \ >> OBJECT_GET_CLASS(XICSStateClass, (obj), TYPE_XICS) >> >> +#define XICS_GET_PARENT_CLASS(obj) \ >> + (XICSStateClass *) object_class_get_parent(object_get_class(obj)) > > This is dangerous in that it takes the parent class of whatever type the > obj argument turns out to have. This has been discussed in lengths in > the context of Peter C.'s proposal for ISA/ARM realize cleanup.
How is it dangerous? I perfectly know what I call it with. And simple run will crash QEMU if something is wrong. > This should therefore be a macro per type specifying the TYPE_*, either > for object_class_by_name() or to my proposed macro which abstracts the > implementation to core QOM code. Please, be more specific. What type should be used in macro here - XICS_COMMON or KVM_XICS? I asked already in the other thread but somehow you missed it. Neither really makes sense for me as I believe that get_parent is exactly for the cases (and this is the case) when I do not want to know exact parent type and I already know the current type. Thanks. > XICS_CLASS() would be nicer than open-coding, but why cast here? > DeviceClass can be needed just as well. I do not need DeviceClass, at all, anywhere. I need a pointer to a my specific cpu_setup callback, this is all about it. -- Alexey
