lkml.org 
[lkml]   [2012]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds
On Thu, May 17, 2012 at 5:22 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That's why I think it's unfixable. It started out broken, and I
> presume that 32-bit user land on a 64-bit MIPS/PPC thing either do not
> work, or there's some compat crap (like special user-land headers)
> fixing things up. Or they just don't use that buggered msqid64_ds
> thing at all.

Btw, even if it's unfixable, that doesn't necessarily mean that we
can't make it *prettier*.

For example, instead of this horrible crap:

__kernel_time_t msg_stime; /* last msgsnd time */
#if __BITS_PER_LONG != 64
unsigned long __unused1;
#endif

which is just nasty, we *could* have something much cleaner like this:

#define align_64_entry(type,name) \
union { type name; __u64 __align_##name; }

and then just use

align_64_entry(__kernel_time_t msg_stime);

without any preprocessor #if/#ifdef crap anywhere.

It would keep the current state for the (apparently broken) case of
64-bit kernel and 32-bit user space with big-endian architectures, but
it would *also* just magically work if __kernel_time_t is 64-bit
despite "long" being 32-bit.

So it would fix the x32 case, as far as I can tell.

Note: totally untested. Maybe there's some reason why my anonymous
union trick wouldn't work.

Linus


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