[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FB5C843.9070002@kernel.org>
Date: Thu, 17 May 2012 20:55:47 -0700
From: "H. Peter Anvin" <hpa@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "H.J. Lu" <hjl.tools@...il.com>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, mingo@...nel.org, tglx@...utronix.de,
Paul Mundt <lethal@...ux-sh.org>,
David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds
On 05/17/2012 08:49 PM, Linus Torvalds wrote:
> On Thu, May 17, 2012 at 8:39 PM, H.J. Lu <hjl.tools@...il.com> wrote:
>>
>> That will be wrong. __BITS_PER_LONG defines # bits of long
>> as seen by kernel. We don't use it in user space.
>
> Yes you do. Exactly in that structure that Peter points to. *Exactly*
> because that structure uses "long" instead of some fixed size. Which
> will be different in user mode than in kernel mode.
>
> And if user mode doesn't use these headers at all, then we should stop
> playing the insane games.
>
User mode can, and should, be able to use the exported headers. David
Howells have been doing even more work to distill out the actual
exported ABIs from the kernel and remove remaining chaff.
That being said it seems kind of loopy to expect something called
__BITS_PER_LONG to be anything other than (CHAR_BIT*sizeof(long)),
especially since one of the main uses of it seems to be sizing
bitvectors (which has its own issues on bigendian machines because I
think we do littleendian bit numbering even on bigendian iron).
-hpa
--
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