> "David S. Miller" <davem@dm.cobaltmicro.com> writes:
>
> > 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%.
Well I'm running libc5 on most of my systems. If you get the damn thing
right then I dont have to upgrade anything.
> > 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.
Then leave it to the kernel.
> 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.
Fine, the kernel. It's the kernel's job to initlize hardware. Not
libc's.. Leave the kernel to do what needs to be done. The libc init
shouldn't need to twiddle the FPU.
> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu