40% slowdown with dynamic /bin/sh

[Matthew Dillon]

:Matt, I'm talking about the de facto standard NSS, as found in Solaris
:and Linux; and now FreeBSD 5 [*] and soon NetBSD [**].  You are talking
:about some better mousetrap.  The latter does not have any relevance
:to this thread, which is about dynamic linking in next release of
:FreeBSD.
:
:If you want to talk about FreeBSD 6.x and a better mousetrap, please
:go right ahead with a new thread here on freebsd-current or over on
:freebsd-arch.
:
:If you want to talk about the future of DragonFlyBSD, I'm sure there
:is an appropriate list for that--- this one ain't it.  Parts of your
:message certainly seemed to describe what might be best for some other
:operating system.
:
:Cheers,
:-- 
:Jacques Vidrine   NTT/Verio SME      FreeBSD UNIX       Heimdal
:nectar at celabo.org jvidrine at verio.net nectar at freebsd.org nectar at kth.se
:
:
:Side notes:
:
:[*] The actual APIs used by Solaris and Linux are *very* different;
:and the APIs used by FreeBSD are *somewhat* different from Linux.
:However, because the *core concepts* are the same--- dynamic loading,
:in-process modules--- portability issues are not much of a problem.
:
:[**] NetBSD doesn't support dynamic loading yet, but has had
:considerable influence on the FreeBSD implementation.  NetBSD
:developers have indicated to me that they expect to bring in
:the FreeBSD changes so that there will be basically the same
:implementation on FreeBSD and NetBSD.

    I'm not sure of the relevance of this comment.  My original opinion
    still stands... you guys are using this issue as an excuse to basically
    do away with static binaries, rather then fixing the real problem which
    is an inability to dynamically load modules in a static binary.

    How much do you intend to use NSS for?  I mean, what's the point of
    adopting this cool infrastructure if all you are going to do with it
    is make a better PAM out of it?  You can use it for basic authentication,
    sure, but the more things you try to use it for without static binary
    support the fewer things you can compile statically.  You are basically
    doing away with the static linking capability of the system for no good
    reason that I can see, and coming up with all sorts of extra junk,
    like /rescue, to work around that fact.  You are creating a huge mess
    *JUST* to be able to port a dynamic load NSS framework and you are 
    throwing away functionality left and right to get it.  That's no good
    in my book.  If you *REALLY* want dynamic load NSS then you ought to
    spend the time to make it work with static binaries rather then just
    being lazy and getting rid of static binaries.

    So, yes, I do think you guys are being lazy in that regard.  If this
    is the path you've chosen to go then you have an obligation not to
    tear out major existing system capabilities, such as the ability to
    generate static binaries, in the process.

    If the APIs are totally different then I don't see any difference
    between your direct NSS implementation and my ability, within an 
    IPC framework, to implement NSS as a backend service.  I suppose you
    can call me work "building a better mousetrap", implying that I am
    doing work that has already been done, but it is really no different
    then what you are doing in FreeBSD-5 by changing existing API standards
    to suit your particular implementation.

    There is a lot of circular reasoning going on here... it's the same sort
    of circular reasoning that John uses to justify some of the more esoteric
    scheduling mechanisms in -current.  A because of B because of A, and
    to hell with anyone who wanted to use C.

    What I am doing is not reinventing the wheel, I am simply reinventing the
    API that the backend of libc uses to access resources.  There is nothing
    preventing me from then implementing something like NSS and PAM on the
    backend of the new API, as a service rather then as a DLL.  I fully
    expect that someone will do that, in fact, possibly even me.  But I also
    expect that straight IPC will solve at least as many problems and
    in fact solve significantly more problems then the DLL NSS solution
    solves.

    So, yes, IPC will be the basis used in DFly.  That does not invalidate
    my comments vis-a-vie the dynamic/static problem with NSS and PAM
    that FreeBSD-5 has.  If you want to do it right then make DLL's work
    with static binaries.  If you want to do it wrong then ignore static
    binaries.  It is that simple.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>