Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

[David Daney]

On 05/17/2012 05:14 PM, H. Peter Anvin wrote:
> On 05/17/2012 05:07 PM, Linus Torvalds wrote:
> > On Thu, May 17, 2012 at 4:51 PM, H. Peter Anvin<hpa@xxxxxxxxx>  wrote:
> > > The sane thing would seem to be to change __BITS_PER_LONG to 32 on x32
> > > and fix the padding hacks in struct shmid64_ds; H.J., would you agree?
> >
> > Ugh. That looks like a disaster.
> >
> > The padding hacks that depend on __BITS_PER_LONG seem pretty damn broken anyway.
> >
> > They only work if the kernel agrees with the value (which is against
> > the whole point of making __BITS_PER_LONG be about some user-level ABI
> > thing) or for little-endian machines.
> >
> > IOW, all the __BITS_PER_LONG games look totally broken to me. I can't
> > see how they could possibly even be fixed.
>
> Well, on existing compat (e.g. i386) __BITS_PER_LONG is definitely not
> the same as kernel.  And yes, I don't see how the heck this was ever
> correct on bigendian machines or even for compat in any form (if the
> kernel tries to interpret the extra bits and user space didn't
> initialize them we're lost.)
>
> The "logical" thing to do here seems to just use __s64, but I have no
> idea if that would suddenly break bigendian architectures...
>
> David, Ralf, do you have any idea what e.g. MIPS does here?

At the top of arch/mips/include/asm/types.h we have:

#ifdef __KERNEL__
# include <asm-generic/int-ll64.h>
#else
# if _MIPS_SZLONG == 64
#  include <asm-generic/int-l64.h>
# else
#  include <asm-generic/int-ll64.h>
# endif
#endif

In this case the userspace gcc will define _MIPS_SZLONG according to the 
selected ABI.

in arch/mips/include/asm/bitsperlong.h we have:

#define __BITS_PER_LONG _MIPS_SZLONG

Again, the proper value for the userspace ABI.

This is either 32 or 64 depending which of the three userspace ABIs are 
selected.

I don't know if that answers your question though.

My preference would be that any type that has a width that varies by 
userspace ABI, not include "64" or "32" within its name.

David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/