Re: glibc developers refuse to support user land fake FS syscalls

Richard Gooch (rgooch@atnf.csiro.au)
Sat, 3 Jul 1999 11:12:59 +1000


[Cc list trimmed]
Theodore Y. Ts'o writes:
> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 01 Jul 1999 21:02:32 -0700
>
> > The other option is to do it as a global LD_PRELOAD, as I mentioned
> > earlier.
>
> I don't know how often I repeated this already:
>
> LD_PRELOAD is a *hack*, not a solution.
>
> There have been enough uses of LD_PRELOAD over the years that perhaps
> it's time to consider finding a clean way of giving that sort of
> functionality. Right now the choices are:
>
> * LD_PRELOAD
> * hacking glibc internals
> * throwing features that really shouldn't be implemented in
> the kernel-space into the kernel
>
> Given these choices, LD_PRELOAD seems like one of the cleaner
> alternatives. If you don't like it, what needs to be fixed with it
> so that you'd consider it an acceptably clean alternative?

This is something that I've been thinking about. One thing that I
don't like about LD_PRELOAD is that it's indiscriminant. There's no
control.

I propose a system-wide and per-user configuration file that can be
used to specify extra shared libraries to load. Part of the syntax
would be to limit the extra libraries based on argv[0]. Then various
"interesting" functions in libc would call "known" symbols in these
extra libraries.

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.

I've implemented the overloading technique in one of my libraries, and
it works really well.

> (Keeping in mind that the natives are getting restless, and the
> traditional Unix answer of "No, you really didn't want that feature
> anyway", isn't going to hold them off forever. :-)

The unwashed masses have discovered the ivory tower ;-)

Regards,

Richard....

-
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/