Re: [Qemu-devel] [PATCH 6/6] xics-kvm: Support for in-kernel XICS interrupt controller

[Alexey Kardashevskiy <aik@ozlabs.ru>]

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