40% slowdown with dynamic /bin/sh
scottl at freebsd.org
Mon Nov 24 19:24:21 PST 2003
On Mon, 24 Nov 2003, Matthew Dillon wrote:
> :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.
> :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.
I think that you forgot to attach the patches that demonstrate all of
Also, I'm really starting to resent you using the FreeBSD mailing lists as
an advocacy channel for DragonFly. I fail to see how FreeBSD 4.x and
DFBSD relate to FreeBSD 5-current, which is the overall topic of this
mailing list at the moment.
More information about the freebsd-current