[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878t3wjvmk.fsf@concordia.ellerman.id.au>
Date: Thu, 20 Sep 2018 20:44:51 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: David Howells <dhowells@...hat.com>,
Stephen Rothwell <sfr@...b.auug.org.au>
Cc: dhowells@...hat.com, Al Viro <viro@...IV.linux.org.uk>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the vfs tree
David Howells <dhowells@...hat.com> writes:
> Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
>> > After merging the vfs tree, today's linux-next build (powerpc
>> > allyesconfig) failed like this:
>> >
>> > samples/vfs/test-fsinfo.c: In function 'fsinfo':
>> > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?
>
> I think the problem is that I haven't allocated system call numbers for any
> arches other than x86 - even the x86 syscall numbers are provisional until the
> patchset is taken upstream. I'm not sure of the best way to deal with this -
> make the samples dependent on the X86 arch?
>
>> > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long unsigned int'} [-Wformat=]
>> > printf("\tmax file size: %llx\n", f->max_file_size);
>
> Sigh. On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> long. Is it possible to shift all arches to use unsigned long long for __u64?
You can #define SANE_USERSPACE_TYPES to get ll64 for powerpc.
cheers
Powered by blists - more mailing lists