[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 16:42:43 +0100 > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > index 6a198e4..6c5ad83 100644 > > > --- a/include/xen/xen-ops.h > > > +++ b/include/xen/xen-ops.h > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > > vstart, unsigned int order, void > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > order); struct vm_area_struct; > > > +struct xen_pvh_pfn_info; > > > > If you move the struct def'n up you don't need this forward decl. > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid); > > > + pgprot_t prot, unsigned domid, > > > + struct xen_pvh_pfn_info *pvhp); > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_pvh_pfn_info *pvhp); > > > + > > > +struct xen_pvh_pfn_info { > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > > while this struct is also useful on ARM. > > I already renamed it to: xen_xlat_pfn_info. What does xlat refer to here? I don't think we translate anything with this struct. > > > + struct page **pi_paga; /* pfn info page > > > array */ > > > > can we just call this "pages"? paga is pretty meaningless. > > page array! i can rename page_array or page_a. What's wrong with pages? It's short (some of the lines using this stuff are necessarily pretty long) and obvious. > > > + int pi_num_pgs; > > > + int pi_next_todo; > > > > I don't think we need the pi_ prefix for any of these. > > The prefix for fields in struct make it easy to find via cscope or > grep, otherwise, it's a nightmare to find common field names like > pages when reading code. I really get frustrated. I prefer prefixing > all field names. It's not common practice in Linux to do so but fair enough. While implementing the ARM version of this interface it occurred to me that the num_pgs and next_todo fields here are not really needed across the arch interface e.g. you already get pi_num_pgs from the nr argument to xen_remap_domain_mfn_range and pi_next_todo is really state which fits in struct pvh_remap_data. That would mean that remap_foo could take a struct page * directly and I think you would save an allocation. I may look into implementing that change as I code up the ARM side. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |