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
