Re: 40% slowdown with dynamic /bin/sh

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Mon, 24 Nov 2003 19:11:29 -0800 (PST)
: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>
Received on Mon Nov 24 2003 - 18:11:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC