Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing

Ingo Molnar
2011-12-08T04:49:44Z

* Matt Evans <matt@ozlabs.org> wrote:

> On 08/12/11 04:14, Pekka Enberg wrote:
> > On Wed, 7 Dec 2011, Ingo Molnar wrote:
> >
> >>
> >> * Matt Evans <matt@ozlabs.org> wrote:
> >>
> >>>>> [...] I haven't looked closely at Matt's
> >>>>> patches, but it should be possible to use [un]signed long long
> >>>>> for the u64/s64 types, I would think.
> >>>>
> >>>> In tools/kvm/ we are using our own u64/s64 definitions, not
> >>>> glibc's, so i think it should be fine - as long as we don't pick
> >>>> up int-l64.h accidentally via the
> >>>> arch/powerpc/include/asm/types.h exception for user-space.
> >>>
> >>> That's what's happening here; we're __powerpc64__ and
> >>> !__KERNEL__, tools/kvm/include/linux/types.h includes
> >>> asm/types.h so gets the int-l64.h definition of __u64, as
> >>> above. :/
> >>>
> >>> builtin-run.c:389: error: format `%llx' expects type `long
> >>> long unsigned int', but argument 2 has type `u64'
> >>
> >> So either define __KERNEL__ or patch a __NEW_USERSPACE__ define
> >> into power/asm/types.h and use it - if the PowerPC folks agree
> >> with that approach.
> >>
> >> Sane userspace should not be prevented from using the same sane
> >> types the kernel is already using :-)
> >
> > How does perf handle this? I'm sure it has the exact same
> > issue, doesn't it?
>
> It does; ironically it uses PRIblah, so I had followed its
> example.

Sadly it regressed lately in that area - it was certainly
PRIblah-less in the early stages :-)

Pekka, how do the headers react if we define __KERNEL__?
Alternatively, allowing an override in powerpc/types.h beyond
__KERNEL__ looks sensible as well.

Thanks,

Ingo