[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V5 09/10] xen/arm: make domain_max_vcpus return value from vgic_ops



On 31/05/15 19:05, Julien Grall wrote:
> Hi Chen,
>
> On 31/05/2015 16:31, Chen Baozi wrote:
>>> On May 31, 2015, at 21:35, Julien Grall <julien.grall@xxxxxxxxxx>
>>> wrote:
>>>> +
>>>>   #define NR_GIC_LOCAL_IRQS  NR_LOCAL_IRQS
>>>>   #define NR_GIC_SGI         16
>>>>   #define MAX_RDIST_COUNT    4
>>>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>>>> index 2f413e1..1157b04 100644
>>>> --- a/xen/include/asm-arm/vgic.h
>>>> +++ b/xen/include/asm-arm/vgic.h
>>>> @@ -110,6 +110,8 @@ struct vgic_ops {
>>>>       struct vcpu *(*get_target_vcpu)(struct vcpu *v, unsigned int
>>>> irq);
>>>>       /* vGIC sysreg emulation */
>>>>       int (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr
>>>> hsr);
>>>> +    /* Get the maximum number of vCPU supported */
>>>> +    int (*get_max_vcpus)(void);
>>>
>>> Why did you create a function? The value never change so a field
>>> value would have been better…
>>
>> But is it appropriate that we define a field value in a struct called
>> vgic_ops? I
>> thought ‘XXX_ops’ refers to a struct that is made up by function
>> points. (FIXME)
>
> Well if the only issue if the name, please rename the structure. IHMO,
> the name is fine for me, I will let Ian & Stefano decides about it.
>
> As the vGIC is always supporting N cpus and will never change, it's
> pointless to use a function (thinking about the "cost" vs access an
> field).

We have plenty of other structures with mixed function pointers and data.

A "const unsigned int max_vcpus;" should absolutely be used in a case
like this.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.