Messages in this thread | | | From | David Petrou <> | Subject | Re: glibc developers refuse to support user land fake FS syscalls | Date | Mon, 5 Jul 1999 14:10:59 -0400 (EDT) |
| |
> An alternative is that "interesting" functions in libc allow the > application to register overload functions. Each interface function > (i.e. open(), stat() and so on) would call the overload function > first. If that fails, the next overload function is called (yep, a > stack). Finally, the internal implementation is called if none of > the overload functions succeed. You can even set it up so that if > an overload function calls the calling interface function, the next > overload function is called.
We've done something similar in the Solaris kernel at the syscall and signal interfaces; the advantage of the kernel approach being that extensions are forced upon applications. With libraries, apps can circumvent extensions by making the syscalls directly, making it hard to enforce "security" extensions. This distinction may or may not be important to you...
Our interposition layer has three properties: Transparency (i.e.: no interface changes, works with statically linked code, etc.), it's incremental, and composable. By incremental, you can extend any subset of the syscall space, whatever you're interested in. By composable, you can have multiple extensions running simultaneously in a stack. The sysadm decides on the (sometimes non-trivial) ordering of the extensions within a stack. Extensions can act on all threads, or some subset, and optionally any forked children.
We got a fair bit of experience making the above fast and writing sample extensions. Here's the URL of our writeup from USENIX 98: http://www.cs.cmu.edu/~dpetrou/papers/slic98.ps
David
- 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/
| |