40% slowdown with dynamic /bin/sh
dillon at apollo.backplane.com
Tue Nov 25 12:39:17 PST 2003
: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
: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
: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
:Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal
:nectar at celabo.org jvidrine at verio.net nectar at freebsd.org nectar at kth.se
:[*] 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
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.
<dillon at backplane.com>
More information about the freebsd-current