On 08/12/11 15:49, Ingo Molnar wrote: > > * Matt Evans <m...@ozlabs.org> wrote: > >> On 08/12/11 04:14, Pekka Enberg wrote: >>> On Wed, 7 Dec 2011, Ingo Molnar wrote: >>> >>>> >>>> * Matt Evans <m...@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 :-)
Oh dear :-) > Pekka, how do the headers react if we define __KERNEL__? > Alternatively, allowing an override in powerpc/types.h beyond > __KERNEL__ looks sensible as well. Well, I just tried it and it ended in tears; various things bring in tons more (ppc) stuff from asm/, quite a few conflicts. I've resorted to defining __KERNEL__ in linux/types.h *only* around #include <asm/types.h> (i.e. undefining it afterwards). This picks up the correct int-ll64.h on PPC64 and doesn't break everything else. Cheers, Matt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
