Re: 40% slowdown with dynamic /bin/sh

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
this.

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.

Scott