40% slowdown with dynamic /bin/sh

Scott Long 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.
> :
> :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.

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 mailing list