> Because the solution I propose allows anyone using any kernel existing
> right now to have something which works. Your solution requires a
> kernel upgrade and changes to both glibc and the kernel.
How many people do upgrade their libc more often than the kernel? I
would be very surprised if this is more than 50%.
> I've been watching glibc set the FPU csr to zero on all architectures,
> most of which give the user a zero'd FPU csr when it starts up, for
> every process which ever runs, annulling any optimizations I do to
I agree that currently the instructions do effectively nothing for
most processes. But what happens if the kernel changes the init
values, that's the point. If you have all the code in one place this
is no problem. But requiring synchronization between the kernel and
the libc is exactly what everybody wants to avoid.
I agree completely that changing the startup code is the easiest way
to fix the problem for the moment. But we simple trigger a timebomb.
Encapsulate all the needed information in one place.
There is one more solution: let the kernel report what CW value it
will use. Maybe in the ELF auxiliary vector. Add AT_LINUX_FPUCW and
pass the value up. Then the libc can decide whether it is necessary
to perform the operation or not. And we have no dependencies except
that you need to upgrade your system to take advatnage of the
improvements but this is the same for most enhancements.
-- Uli
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu