| Message ID | alpine.DEB.2.02.1403261904540.2747@kaball.uk.xensource.com |
|---|---|
| State | Accepted |
| Commit | b021348231e942a342fd82e7a60193256236274d |
| Headers | show |
On Wed, 2014-03-26 at 19:09 +0000, Stefano Stabellini wrote: > Replace unsigned long with xen_ulong_t in public/platform.h. > Also replace unsigned int with uint32_t for clarity. It is safe because > unsigned int are 4 byte sized and 4 byte aligned an all the supported > architectures. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> (you surely wanted to CC Keir for a change to the public API) "git grep -l unsigned.long -- xen/include/public/" produces: xen/include/public/arch-arm.h xen/include/public/arch-x86/hvm/save.h xen/include/public/arch-x86/xen-x86_32.h xen/include/public/arch-x86/xen-x86_64.h xen/include/public/arch-x86/xen.h xen/include/public/arch-x86_64.h xen/include/public/io/fbif.h xen/include/public/io/tpmif.h xen/include/public/kexec.h xen/include/public/nmi.h xen/include/public/physdev.h xen/include/public/platform.h xen/include/public/sched.h xen/include/public/trace.h xen/include/public/xen.h Are any of the others things we should clear up while we are here? arch-arm.h: is legit, used for the guest handle param on 32bit arch-x86*: I think we can discount arch-x86* for these purposes. fbif.h: has "unsigned long pd[256];" tpmif.h: has "unsigned long addr; /* Machine address of packet. */" kexec.h: has several unsigned longs nmi.h: I think ARM won't want PV NMI, it can use h/w facilities physdev.h: apic stuff -- therefore x86 specific sched.h: just a comment, which I think is out of date trace.h: a comment, not sure if it implies something is wrong though xen.h: mostly x86 specific PV interfaces, but multicall_entry is a bit concerning but it seems we haven't implemented multicalls on ARM yet! Phew, I think we are mostly ok...
Ian Campbell wrote: > On Wed, 2014-03-26 at 19:09 +0000, Stefano Stabellini wrote: > - hide quoted text -- show quoted text - >> > Replace unsigned long with xen_ulong_t in public/platform.h. >> > Also replace unsigned int with uint32_t for clarity. It is safe because >> > unsigned int are 4 byte sized and 4 byte aligned an all the supported >> > architectures. >> > >> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com> > > Acked-by: Ian Campbell<ian.campbell@citrix.com> Seems a good idea to me. Acked-by: Keir Fraser <keir@xen.org>
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h index 4341f54..053b9fa 100644 --- a/xen/include/public/platform.h +++ b/xen/include/public/platform.h @@ -134,7 +134,7 @@ struct xenpf_efi_runtime_call { * where it holds the single returned value. */ uint32_t misc; - unsigned long status; + xen_ulong_t status; union { #define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001 struct { @@ -168,7 +168,7 @@ struct xenpf_efi_runtime_call { #define XEN_EFI_VARIABLE_RUNTIME_ACCESS 0x00000004 struct { XEN_GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ - unsigned long size; + xen_ulong_t size; XEN_GUEST_HANDLE(void) data; struct xenpf_efi_guid { uint32_t data1; @@ -179,7 +179,7 @@ struct xenpf_efi_runtime_call { } get_variable, set_variable; struct { - unsigned long size; + xen_ulong_t size; XEN_GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ struct xenpf_efi_guid vendor_guid; } get_next_variable_name; @@ -194,14 +194,14 @@ struct xenpf_efi_runtime_call { struct { XEN_GUEST_HANDLE(void) capsule_header_array; - unsigned long capsule_count; + xen_ulong_t capsule_count; uint64_t max_capsule_size; - unsigned int reset_type; + uint32_t reset_type; } query_capsule_capabilities; struct { XEN_GUEST_HANDLE(void) capsule_header_array; - unsigned long capsule_count; + xen_ulong_t capsule_count; uint64_t sg_list; /* machine address */ } update_capsule; } u;
Replace unsigned long with xen_ulong_t in public/platform.h. Also replace unsigned int with uint32_t for clarity. It is safe because unsigned int are 4 byte sized and 4 byte aligned an all the supported architectures. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>