> 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/