[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMe9rOoH4GbJ5LQxYnySoh-mpLuaA3kPuHj0r=OhJN+xCs4dBQ@mail.gmail.com>
Date: Thu, 17 May 2012 20:59:06 -0700
From: "H.J. Lu" <hjl.tools@...il.com>
To: "H. Peter Anvin" <hpa@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
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 Thu, May 17, 2012 at 8:55 PM, H. Peter Anvin <hpa@...nel.org> wrote:
> 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).
>
But __BITS_PER_LONG used in kernel header files really
means "long" as seen by kernel, not by user space. 64-bit
kernel can have 32-bit and 64-bit longs in use space.
__BITS_PER_LONG is a bad name for user space.
--
H.J.
--
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