lkml.org 
[lkml]   [2012]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2012-05-18 03:01    [W:0.102 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site