Where is FreeBSD going?

[Miguel Mendez]

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 :)

>     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.

>     but there are a lot of things in there that people are going to want
>     to rewrite in coming years, and rewriting by people other then the
>     original authors is one of the reasons why we had so much trouble in
>     the 2.x and 3.x days.  Look at how little VFS has been touched in the

It depends whether we're talking about evolutionary changes or 
revolutionary changes. Are you talking about radical changes like e.g. 
moving from the BSD scheduler to ULE or more like interface and code 
refactorization? In the former, yes, new bugs will be introduced, which 
leads again to the problem of too complex code managed by too few people.

>     I mean, I don't think anyone can honestly say that the scheduler is
>     'done', or even close to done.  Look at how long the original 42 scheduler

IMHO ULE is making progress quite fast. I wouldn't rely on it for 
production, but so far is looks very good.

>     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.

>     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.

Yes, I mentioned DragonFly (how dare he!). Feel free to flame, I've 
become extremely efficient at adding people to /etc/postfix/access :-P

Cheers,
-- 
	Miguel Mendez <flynn at energyhq.es.eu.org>
	http://www.energyhq.es.eu.org
	PGP Key: 0xDC8514F1