But the syscall stuff _is_ the same issue.
Statically recompiling glibc is practically impossible. It just doesn't
make sense to have people having two different versions of glibc for two
different machines. I _think_ you agree, although I'm still not quite
sure.
The reason I'm suggesting a global page is _exactly_ to allow machine- and
kernel-dependent operations that are invisible to process startup. That's
why I suggested it in the first place, and that's why it's exactly the
same old discussion about faster process startup.
Because doing it dynamically in glibc just automatically requires that now
ld.so or something has to check the machinedependent flags at each process
startup. For things like GNU Emacs, that may not be a big deal ("oh,
what's a few thousand extra cycles when the program takes 2 seconds
to start up anyway"), but for other stuff it is lethal.
> - and I'm already working (for some time) on changes to improve the
> startup costs where you will only use the current mechanisms if
> you are preloading or replace libraries. But to implement this I
> have to start from ground up which means rewriting binutils and this
> takes time. In the end you'll never see relocations being performed
> unless you are preloading/changing libraries (where the situtation in
> the later case can be rectified).
Wonderful.
Linus
-
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/