Messages in this thread | | | Date | Fri, 2 Jul 1999 22:33:36 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: glibc developers refuse to support user land fake FS syscalls |
| |
From: Ulrich Drepper <drepper@cygnus.com> Date: 02 Jul 1999 18:00:08 -0700
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/
| |