: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>Received on Tue Nov 25 2003 - 11:39:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:31 UTC