* Matt Evans <matt@xxxxxxxxxx> wrote: > On 08/12/11 04:14, Pekka Enberg wrote: > > On Wed, 7 Dec 2011, Ingo Molnar wrote: > > > >> > >> * Matt Evans <matt@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
