* 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 -
On 12/07/2011 09:16 AM, Ingo Molnar wrote:
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
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
On 12/07/2011 09:16 AM, Ingo Molnar wrote:
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
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
* 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,
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
On 08/12/11 15:56, Matt Evans wrote:
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
* Matt Evans m...@ozlabs.org wrote:
Since tools/kvm/include/linux/types.h only requires __u32,
__u64 et al from asm/types.h, wouldn't it be most
straightforward to just #include asm-generic/int-ll64.h?
This avoids #define __KERNEL__ breaking other includes brought
into userland, avoids
On 08/12/11 16:49, Ingo Molnar wrote:
* Matt Evans m...@ozlabs.org wrote:
Since tools/kvm/include/linux/types.h only requires __u32,
__u64 et al from asm/types.h, wouldn't it be most
straightforward to just #include asm-generic/int-ll64.h?
This avoids #define __KERNEL__ breaking other
* 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 -
On 12/07/2011 09:16 AM, Ingo Molnar wrote:
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
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
On 12/07/2011 09:16 AM, Ingo Molnar wrote:
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
* 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,
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
On 08/12/11 15:56, Matt Evans wrote:
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
* Matt Evans m...@ozlabs.org wrote:
Since tools/kvm/include/linux/types.h only requires __u32,
__u64 et al from asm/types.h, wouldn't it be most
straightforward to just #include asm-generic/int-ll64.h?
This avoids #define __KERNEL__ breaking other includes brought
into userland, avoids
On 08/12/11 16:49, Ingo Molnar wrote:
* Matt Evans m...@ozlabs.org wrote:
Since tools/kvm/include/linux/types.h only requires __u32,
__u64 et al from asm/types.h, wouldn't it be most
straightforward to just #include asm-generic/int-ll64.h?
This avoids #define __KERNEL__ breaking other
Ingo actually got us to remove all the PRI* specifiers, but that was
back when we only did x86 :)
Ingo, does it make sense to use them now when we support different
architectures?
On Tue, 2011-12-06 at 14:38 +1100, Matt Evans wrote:
On LP64 systems our u64s are just longs; remove the %llx'es in
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did x86 :)
Ingo, does it make sense to use them now when we support
different architectures?
Not at all - ppc should use a sane u64/s64 definition, i.e.
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did x86 :)
Ingo, does it make sense to use them now when we support
different
* Paul Mackerras pau...@samba.org wrote:
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did x86 :)
Ingo, does it make sense to
Hi Ingo,
On 06/12/11 21:24, Ingo Molnar wrote:
* Paul Mackerras pau...@samba.org wrote:
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did x86 :)
Ingo, does it make sense to use them now when we support
different architectures?
Not at all - ppc should use a sane u64/s64 definition, i.e.
* Paul Mackerras pau...@samba.org wrote:
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did x86 :)
Ingo, does it make sense to
Hi Ingo,
On 06/12/11 21:24, Ingo Molnar wrote:
* Paul Mackerras pau...@samba.org wrote:
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did
On LP64 systems our u64s are just longs; remove the %llx'es in favour of PRIx64
etc.
This patch also adds CFLAGS to the final link, so that any -m64 is obeyed when
linking, too.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/Makefile |2 +-
tools/kvm/builtin-run.c | 14
28 matches
Mail list logo
