Re: [PATCH 08/24] parisc/uapi: Use Kbuild logic to provide <asm/types.h>

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2013-11-25 at 11:12 +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 25, 2013 at 10:55 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Mon, 2013-11-25 at 09:55 +0100, Geert Uytterhoeven wrote:
> >> Uapi <asm-generic/types.h> just includes <asm-generic/int-ll64.h>
> >
> > This really doesn't look like a good idea:  Firstly the default of
> > asm-generic/types.h should *not* be int-ll64, because that's for 32 bit
> > only and most processors are moving towards 64 bit.  Secondly parisc
> 
> In kernelspace, both 32 and 64 bit are ll64.

Not necessarily; the files exist because of variations in gcc.  Some
versions of gcc have long long being 128 bits and for those you have to
use int-l64.h

> > currently only has a 32 bit userspace, which is why the file is a simple
> > include of int-ll64.h; however, people are working on 64 bit userspace
> 
> Sorry, I didn't know you support 32 bit userspace only.
> 
> > (albeit very slowly) and that file would then have to change.  If we
> > take the file away someone will forget to add the changed file back.
> 
> However, is this a "new" 64 bit userspace ABI? If yes, you may want to
> consider using ll64 in userspace on 64 bit too, like all "new" 64 bit ports
> do (arm64, s390, sparc, tile, x86). Only legacy alpha, ia64, mips and
> old ppc use l64.
> 
> Or follow the ppc64 road:
> 
> /*
>  * This is here because we used to use l64 for 64bit powerpc
>  * and we don't want to impact user mode with our change to ll64
>  * in the kernel.
>  *
>  * However, some user programs are fine with this.  They can
>  * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
>  */
> #ifndef __KERNEL__
> #if !defined(__SANE_USERSPACE_TYPES__) && defined(__powerpc64__)
> # include <asm-generic/int-l64.h>
> #else
> # include <asm-generic/int-ll64.h>
> #endif
> #endif

That's the one I was thinking we might need.

James