40% slowdown with dynamic /bin/sh
Matthew Dillon
dillon at apollo.backplane.com
Mon Nov 24 19:11:35 PST 2003
:Ding! "Oh god, not another one!" *plonk*
:
:We need nsswitch type functionality in /bin/sh. To the people who want to
:make it static, lets see some static binary dlopen() support or a nsswitch
:proxy system.
:
:If half as much effort had been spent on implementing such a thing as there
:has been hand wringing, then we'd have the best of both worlds by now.
:
:I'm sorry to sound harsh, but its the reality of the situation. Code
:speaks louder than words.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
:"All of this is for nothing if we don't go to the stars" - JMS/B5
You don't need dynamic loading to get nsswitch type functionality. You
only need dynamic loading if nobody is willing to write an IPC
model to get the functionality. It's really silly to create such a
fundamental restriction on the binary because people are too lazy
to build an IPC based mechanism. Not only silly, but it seems to me
that it also creates security issues. At least with a client/server
model it is possible to isolate the authentication code to, for example,
disallow exec(), filesystem operations, or the opening of any new files.
The other huge advantage that IPC has over DLL is that you can switchout
the backend mechanisms on a running system without killing and restarting
anything other then he one service you want to switch out, and if it
doesn't work right you can restart the old one or keep live as a fallback.
the IPC model is so much better then the DLL model for this sort of thing
I don't understand why people are even arguing about it.
And, of course, moving all of this junk out means that the libc
implementation becomes a lot smaller... it just becomes an IPC interface
and may be a small local cache rather then the full blown algorithm.
The result? Static binaries become a lot smaller too (not that that
is really a problem anyway).
This 'it has to be static so dlopen works' argument is just not a good
argument. It's really more of an excuse then an argument. If you
really want to use dlopen then make it work with static binaries.
If you want to do it right, develop an IPC model or use an existing
IPC model.
That said, an IPC model is precisely what I am developing for DragonFly
(a 'money where your mouth is' response). :-) Right now I'm building
it as a userspace library but I intend to move the rendezvous code
directly into the kernel. Unix domain sockets are so icky(!). They work,
but they are icky. I intend to use it for all resource and
authentication lookups... password, group, services, pam equivalent,
kerberos, resolver, and so on and so forth. Hell, I think I might use
it for C locale too just to be able to rip locale out of libc.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-current
mailing list