Where is FreeBSD going?

[dyson at iquest.net]

Quoting Miguel Mendez <flynn at energyhq.es.eu.org>:

> Matthew Dillon wrote:
> 
> >     interdisciplinary people left in the project.  The SMP interactions
> >     that John mentions are not trivial... they would challenge *ME* and
> >     regardless of what people think about my social mores I think most
> >     people would agree that I am a pretty good programmer.
> 
> My thoughts exactly. Every time I have this kind of argument, be it on 
> irc or in a mailing list, I get told that Sun needed X years to do the 
> fine grained locks in Solaris and other similar crap. Solaris was 
> possible because Sun could throw more engineers at the problem if 
> needed. FreeBSD is not in such situation. How many people have intimate 
> knowledge of the VM subsystem? How many people besides John Baldwin have 
> ever touched the SMPng code? I don't think anybody has doubts about your 
> programming-fu, btw :)
>
One comment:  I doubt that I could do the things that I used to be able
on FreeBSD.  However, it has been my position (for years), that the
many-mutex ad-hoc approach would require brilliant people to implement,
and incredibly brilliant people to maintain.  (I have lost alot of
context -- due to persistent burnout, but still remember alot of
the problems.)


> 
> >     serious trouble down the line.  The idea (that some people have stated
> >     in later followups to this thread) that the APIs themselves will
> >     stabilize is a pipedream.  The codebase may become reasonably stable,
> 
> Agreed. Like I've said, the main problem I see is complexity. It 
> wouldn't matter as much if there were 5-10 people with deep knowledge of 
> SMPng, but with 1 or 2 hackers working on it, the chance that everything 
> will be ever fixed is quite small.
> 
IMO, the easiest way to start the SMP work (from a FreeBSD monolithic
approach), is to flatten as much of the VFS/VM code as possible into
a continuation scheme...  That is something that I could have done 5yrs
ago in a few weeks, and then keep the networking system as it is.
There would be shims deployed that would still support the sleep/wakeup
scheme, so that the non-networking could and the new flat interface could
be debugged...  (It is NOT a good idea to bug the networking guys until
the new scheme would be debugged.)

At that point, there would be a code with explicit context carried around,
and no nesting or stack context.  This would have a small benefit of avoiding
multiple deeply nested kernel stacks...

Given the very flat scheme, each subsystem could be recoded into a
message passing or simple continuation scheme (whatever is appropriate.)
The system would be naturally able to be reworked -- without the
hidden dependencies of the stack.  VFS/VM layering problems then
become resolvable.

This is NOT a total solution, but should be the beginning of a thinking
exercise that seems to lead into the correct direction.  (Don't
criticize this based upon the completeness of my prescription, but
on what can eventually be developed!!!)



> 
> IMHO ULE is making progress quite fast. I wouldn't rely on it for 
> production, but so far is looks very good.
> 
The need for a new scheduler (or extreme rework on BSD) whenever you
see the threads bouncing around from CPU to CPU.  My temporary hack
solutions couldn't work right, and it is good that the issue is being
researched.


> >     non-interrupt threads due to priority borrowing, and non deterministic
> >     side effects from blocking in a mutex (because mutexes are used for
> >     many things now that spl's were used for before, this is a very
> >     serious issue).
> 
> Yes, that's the main problem I see, not much on the scheduler side, but 
> on the 6-trillion-mutexes side.
>
The IQ of the maintainers would probably have to be 6-trillion, which
would definitely allow the very few elegible developers to maintain
their high priest status forever :-).


 
> >     See?  I didn't mention DragonFly even once!  Ooops, I didn't mention
> >     DFly twice.  oops!  Well, I didn't mention it more then twice anyway.
> 
> Makes me wonder if some of the solutions proposed by DragonFly could be 
> ported to FreeBSD, but I doubt it will be done, since it's more or less 
> admitting that the current solution is wrong.
> 
Sometimes, I think that people have their egos directed wrongly... 
The egos should be fed by the excellent behavior/performance/reliability
of the FreeBSD OS.  Being embarassed about appropriately borrowing
code or ideas from other sources (WITH APPROPRIATE ATTRIBUTION) is
counter productive.

A developer should be able to say "I was wrong, or my code/design
needs rework", without any problems.  No-one produces the golden
perfect code for the first iteration!!!

Oh well -- I cannot think too much about this stuff, or I'll actually
get emotionally involved again.  I need to get a 'normal' job, not
working at home and need to interact with people instead of CRTs. :-).
(I give a sh*t about FreeBSD, and hope that WHATEVER problems that
truly exist are fully resolved.)  There is alot of blood sweat and
tears in that codebase, and being involved in the project should be
done with great respect.

John