Anything which influences the symbol lookup path in the dynamic linker
is preventing optimizations (in the lookup process == faster startup
and generally faster ld.so). I don't want this.
What's wrong with upcalls for these kind of situations?
An upcall means that you have to go from user space to kernel space back
to user space, which would be a performance loss. It's also much easier
to make these sorts of calls from user space than from kernel space.
The bottom line is that someone's going to have to pay the performance
penalty, and the hair has to go somewhere, if we're going to have this
kind of extensibility.
If speed in the the symbol lookup path is the issue, the other thing
that can be done is to check for overrides each time a libc function is
run, by having a function pointer table of override functions. Then
each time, say, open() is called, open can check its entry in the
override table to see if it needs to call an override function first.
When an executable is first started, some standard search path would be
consulted to see if one or more shared libraries should be loaded to
patch the overide function table.
Perhaps the override function table seems ugly, but remember that's
exactly what the kernel would have to do in order to do the upcall,
except that the hair of doing a kernel->user space transition would be
avoided.
- Ted
-
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/