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:0.069 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site