Re: glibc developers refuse to support user land fake FS syscalls
Alexander Kjeldaas (astor@fast.no)
Mon, 5 Jul 1999 15:00:22 +0200
On Fri, Jul 02, 1999 at 10:33:36PM -0400, Theodore Y. Ts'o wrote:
> 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.
>
I know this won't help the current situation, but for the future, how
about changing the way syscalls are invoked. Instead of using int
0x80, do a jump to an absolute location which in turn does the int
0x80. The page that includes the instructions to do system-calls
could be COWable. For a virgin process, a default page is mapped into
the process vm-space. This would make it possible to intercept
system-calls in user-space with a small overhead.
One can also imagine that this page will be kept across exec so that
you can "preload" a library and all processes forking out of that
process will have that library "preloaded".
astor
--
Alexander Kjeldaas, Fast Search & Transfer, Trondheim, Norway
-
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/