lkml.org 
[lkml]   [1999]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] string.h speedup, cld-2.3.30-A1

    On Sat, 27 Nov 1999, Artur Skawina wrote:

    > first, namespace polution, eg copy_struct() would be safer and less
    > conflict prone.

    yep, agreed.

    > third, gcc unconditionally generating clds everywhere is a compiler
    > issue, which should be fixed in compiler land. something like
    > -mno-implicit-clds. (working around the problem by disabling gcc
    > optimizations isn't an optimal solution)

    i believe the 'ideal' solution would be to let users override GCC's
    internal memcpy/etc. functions. Right now it's about cld's. But maybe in
    the (not so far) future we want to use SIMD instructions to do memory
    copies, etc.

    > as an additional datapoint - i didn't see any problems either, during
    > the last couple of months that i ran w/o (most of) the clds.

    great, although problems in this case are never visible during normal use.
    This is what makes this issue tricky.

    > these changes are visible to userland; either your previous
    > /cld-ifdef-KERNEL approach/ or simply /#ifdef-KERNEL the whole header/
    > would probably be safer.

    ok, agreed. Although these days anything that is using kernel headers is
    more or less considered buggy. glibc 2.0+ has it's own string.h.

    will resend the patch with these things fixed, once the 2.3.30
    NUMA/bootmem changes stabilize.

    -- mingo


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:2.024 / U:1.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site