WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0 of 3] management tools portability


I believe the agreement we reached earlier was that *internally* (on any
side of any interface), passing around a single PFN can be type
'unsigned long', since on 32-bit systems that still lets you manage 42
bits of physical memory, and that "should be good enough for anybody."

Yes. It's only the interface we want to change.

Unrelated to that, I converted all 'unsigned long' in the *interface* to
be u64. The one exception is that PFN arrays (not single PFNs) became
'xen_pfn_t'.

Does that make sense?

It seems weird/arbitrary to me to change the type only of PFNs that are array elements.

 -- Keir

--
Hollis Blanchard
IBM Linux Technology Center



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel