>>>> I don't trust him either. Among other things, he changed signal()
>>>> behavior. Gee, thanks for breaking all the apps with SysV expectations.
>>>
>>> Any program that counts on the behavior of signal() in this manner
>>> is broken and should itself be patched to use sigaction or to be
>>> more robust in any of several ways.
>>
>> No. The behavior was well-defined on Linux until Drepper broke it.
>
> Any program that counts on the behavior of signal() in this manner is
> broken. What part of that isn't clear?
Nothing. It is clearly wrong. I've seen software that used #ifdef to
handle Linux, with adjustments for (previously) known Linux behavior.
It is also the proper UNIX behavior. (BSD is free, so no need to clone it)
> This is off-topic on the kernel list anyway.
It wasn't until you deleted the part about the FPU behavior.
It is rather insulting to see Drepper claim the kernel ABI will
be suddenly changed in that way, especially considering his own
track record.
Anyway:
Drepper is simply wrong about the FPU behavior. The kernel must clear
the FPU state anyway to prevent information leaks. (basic C2 security)
The kernel must not break the ABI that all existing Linux executables
expect. Duh. Considering all the effort put into fork+exit latency,
it is horrid to see it all wasted by glibc bloat.
-
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/