[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwyem9KoPMhYkE-vcaUDqgP9g7arHbmD-mMHMSKXaRBOw@mail.gmail.com>
Date: Thu, 17 May 2012 17:22:24 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: David Daney <ddaney.cavm@...il.com>,
Ralf Baechle <ralf@...ux-mips.org>,
"H.J. Lu" <hjl.tools@...il.com>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, mingo@...nel.org, tglx@...utronix.de
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds
On Thu, May 17, 2012 at 5:14 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> The "logical" thing to do here seems to just use __s64, but I have no
> idea if that would suddenly break bigendian architectures...
Well, it would break the case of a 32-bit kernel and 32-bit user land.
So the thing is, that the __BITS_PER_LONG games there currently work
for two cases:
- when the kernel and user land agree on either 32-bit or 64-bit
(this is probably the common MIPS/PPC case)
- when the kernel is 64-bit, user-land is 32-bit, and we're little-endian
Using __s64 would actually break old 32-bit big-endian cases, because
the 32-bit binaries would continue to read the first 32 bits, while a
32-bit kernel would consider the first 32 bits to be the *high* bits
of the __s64 value.
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.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists