Re: [Xen-devel] [PATCH] public/platform.h: replace unsigned long with xen_ulong_t

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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@xxxxxxxxxxxxx>

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

(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...



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel