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

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

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,


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.


Julien Grall

Xen-devel mailing list



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