Messages in this thread | | | Date | Thu, 17 May 2012 17:29:39 -0700 | From | David Daney <> | Subject | Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds |
| |
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@zytor.com> 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
| |