Re: [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Julien Grall <julien.grall@linaro.org>]

Hi Manish,

On 16/01/18 13:27, Manish Jaggi wrote:
> 
> 
> On 01/16/2018 06:44 PM, Julien Grall wrote:
>>
>>
>> On 16/01/18 12:40, Manish Jaggi wrote:
>>> Hi Julien,
>>
>> Hi,
>>
>>> On 01/16/2018 02:11 AM, Julien Grall wrote:
>>>>
>>>>
>>>> On 01/03/2018 05:34 AM, Manish Jaggi wrote:
>>>>> Hi Sameer,
>>>>
>>>> Hi Manish,
>>>>
>>>>>> +    unsigned int            type;
>>>>>> +
>>>>>> +    /* Dummy compatibility defines */
>>>>>> +    unsigned long pgsize_bitmap;
>>>>>> +    struct iommu_domain_geometry geometry;
>>>>>> +
>>>>>> +    atomic_t ref;
>>>>>> +    /* Used to link iommu_domain contexts for a same domain.
>>>>>> +     * There is at least one per-SMMU to used by the domain.
>>>>>> +     */
>>>>>> +    struct list_head        list;
>>>>>> +};
>>>>>> +
>>>>>> +/* Xen: Describes information required for a Xen domain */
>>>>>> +struct arm_smmu_xen_domain {
>>>>>> +    spinlock_t          lock;
>>>>>> +    /* List of iommu domains associated to this domain */
>>>>>> +    struct list_head        contexts;
>>>>> Could we use a more verbose name, How about 
>>>>> %s/contexts/iommu_domain_contexts/g ?
>>>>
>>>> How about a much more verbose name...? This name is 21 letters and 
>>>> that's only for the field. Just imagine with the variable name 
>>>> before and a couple of indentation.
>>> How about io_context? anything which makes it more verbose is ok with 
>>> me.
>>
>> I much prefer to stick with "contexts".
> I am not able to understand why to use contexts for a list which has 
> iommu_domain pointers.

Because the comment should have been read "iommu_domain context". As it 
is in other description.

> If you are ok with this logic, we can rename all iommu_domain pointer 
> variables in this file as context.

Why do you keep asking renaming when I clearly said multiple time that 
we *should not* rename any code coming from Linux. This is breaking the 
idea of keeping Xen and Linux SMMU driver close.

If you don't want to get SMMUv3 close to Linux. Then fine, but it means 
you have to use Xen coding style and dropping all necessary code.

But I am afraid this is not the solution I (and AFAIK Stefano) prefer 
because it adds burden on maintenance on Xen community.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel