Re: [Xen-devel] [PATCH V3 2/29] VIOMMU: Add vIOMMU helper functions to create, destroy vIOMMU instance

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.10.17 at 02:51, <tianyu.lan@xxxxxxxxx> wrote:
> On 2017年10月18日 22:05, Roger Pau Monné wrote:
>>> +int viommu_register_type(uint64_t type, struct viommu_ops *ops)
>>> > +{
>>> > +    struct viommu_type *viommu_type = NULL;
>>> > +
>>> > +    if ( !viommu_enabled() )
>>> > +        return -ENODEV;
>>> > +
>>> > +    if ( viommu_get_type(type) )
>>> > +        return -EEXIST;
>>> > +
>>> > +    viommu_type = xzalloc(struct viommu_type);
>>> > +    if ( !viommu_type )
>>> > +        return -ENOMEM;
>>> > +
>>> > +    viommu_type->type = type;
>>> > +    viommu_type->ops = ops;
>>> > +
>>> > +    spin_lock(&type_list_lock);
>>> > +    list_add_tail(&viommu_type->node, &type_list);
>>> > +    spin_unlock(&type_list_lock);
>>> > +
>>> > +    return 0;
>>> > +}
>> As mentioned above, I think this viommu_register_type helper could be
>> avoided. I would rather use a macro similar to REGISTER_SCHEDULER in
>> order to populate an array at link time, and then just iterate over
>> it.
>> 
> 
> Hi Jan:
>       Could you help to check whether REGISTER_SCHEDULER is right direction
> for vIOMMU? It needs to change Xen lds layout. From my view, a list to
> manage vIOMMU device model types will be more easy and this maybe a
> common solution.

I think the suggested approach is generally the neater one; there
may be a few other things we could convert to a similar model, to
clean up code. Hence yes, unless there are strong reasons against
it, I agree with Roger.

Jan

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