Re: linux-next: build failure after merge of the vfs tree

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Hi David,

On Tue, 18 Sep 2018 23:17:21 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.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?

But the sample programs are built with HOSTCC, so you can't depend on
ARCH (since I, for one, am cross compiling).  Maybe SUBARCH.  Better
would be to use either Kconfig's shell primitive or some make magic to
figure out if the syscall number define's are defined.

> > > 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?

I doubt it - that would probably cause more warnings in the arch code.
Instead, just explicitly cast it to unsigned long long.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]