lkml.org 
[lkml]   [2012]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds
    From
    On Thu, May 17, 2012 at 8:55 PM, H. Peter Anvin <hpa@kernel.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@gmail.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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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