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 <[EMAIL PROTECTED]>
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
