DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Am I way off base here?


From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Wed, 26 Nov 2003 16:27:25 +0100

On Tue, Nov 25, 2003 at 04:36:45PM -0800, Galen Sampson wrote:
> I have been reading these threads on current.  I did not get understand 
> that was your arguement from what you posted there.  Your initial post 
> starting this thread did not enlighten me either (which asks if there is 
> something wrong with an IPC approach).  If your arguement was clear and 
> I missed it then you should entertain the possiblity that other missed 
> it as well.  Their reactions may have been strong since they may have 
> heavily invested time and effort into something that they mistakenly 
> think you are putting down that work.

The bad points of the current NSS implementation for FreeBSD and Linux
are (a) its dependency on dlopen() and (b) that it's running in the
calling process. The IPC approach avoids both. It may be slower for
things like /etc/passwd lookups, but as fast as dynamic lib-NSS for
things like LDAP lookups. Using IPC has the advantage of working
for chroot() processes as well, if done correctly.

It should be mentioned that dynamic libs and IPC aren't the only
possible implementations. You could even employ the old NIS code in
libc and provide a local NIS server with whatever you want as backend. 

> 
> I have not seen a well thought out, convincing, argument for or against 
> a dynamic root.  I also don't pretend to know enough about the 
> implications of each to weigh them.  Therefore I am in the position to 
> rely on those who do (I would say that you know far more then I on the 
> subject, but so must others on the core team of FreeBSD).  That said 

The question of dynamic root is an interesting one without
NSS and PAM. I like the idea, since it saves a considerable
amount of space in /, but I would force its use. For a server
I would deploy a static root for the fall-back safety in
emergency situations. But the main problem is not having
dynamic root for NSS, it is having _no static programs at all_.
Since with the current implementation (and supposedly all
practical) a static program cannot fully employ NSS.

> your ideas so far (lwkt_thread/lwkt_msg) seem to be good ones.  I have 
> no reason to think that an IPC NSS will "not work" unless we are not 
> capable of making it work sucessfully.  Actually I like that the ideas 

The situation is very similiar to PAM vs. BSD auth. The later works
without shared libs and can replace almost all uses of PAM and
has some other features not directly possible with PAM. It could be
even possible to provide a bridge between IPC based NSS and "legacy"
NSS modules.

> in dragonfly have not necessarily been done before (just as I liked to 
> read the papers about the MIT exokernel, and K42).  Things can't 
> necessarily be proven correct or incorrect without trying out the idea 
> (of course even then nothing is necessarily proven).  Here we seem to be 
> "trying out" an IPC NSS.  We are in the middle of trying out lwkt_*. 
> Whether lwkt_* is better or worse than anyone else's ideas doesn't 
> necessarily concern me.  It can just be redone/improved to make it 
> better.  The same applies to the IPC NSS idea.  In short this is not a 
> contest to me, more of an exploration.

Research and exploration are highly dangerous battle fields ;-)

> 
> I did not consider any other alternative to NSS then to have a fully 
> dynamic system.  The fact that there is an alternative, and that you 
> voiced it, is a very good thing (it seems that some people 
> miss-interpreted your discussion of that idea, and thats too bad).  The 
> fact that you are implementing it is even better.  It is clear that many 
> people want NSS.  It is also clear that some people want a static root. 
>  Thus the problem becomes "how can we have a static root with support 
> for NSS".  It seems that a large portion of the threads on -current seem 
> to be saying "I want it this way!" without providing a workable solution 
> to "the problem".  Your idea was possibly the only solution posted to 
> the -current list that solves this problem.

See above for another.

> 
> I have been tempted to try to mediate current.  If I owned a "heavy 
> stick" (was respected enough to have my voice heard) I would propose 
> those that want a static root to gather their pros for this 
> implementation (including benchmarks, etc.).  I would also propose those 
> that want a dynamic root to provide their pros.  The benchmarks would be 
> run by everyone.  I would also accept alternative solutions (of which 
> your IPC is one, and dlopen() for static binaries is another).  Then a 
> reasonable discussion could be started with all information at hand. 
> Hopefully a workable compromise could be made.

Like I said before, IMO IPC is better since it doesn't force dynamic
linking (with all its pros and cons) down your throat.

[snip]
> Pesonally it is really sad to see such a small thing (apparently it 
> isn't that small?) as this leave a bad taste in the mouths of many 
> obviously talented people (You + PHK + Scott Long + FreeBSD 
> core/developers).  It seems to me that FreeBSD is good, and has the 
> potential to be great.  Things like this only hurt it.

What was said in the SCO thread about the ego of BSD developers?
I like to BSDs for thinking about how to improve Unix by researching
what can be changed and how it is best done. Hopefully it will
stay that way.

Joerg

> 
> Regards,
> Galen
> 
> 



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]