Date: Thu, 08 Jan 2004 08:07:58 +0100 From: Miguel Mendez <flynn@energyhq.es.eu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: jsd@jdyson.com Subject: Re: Where is FreeBSD going? Message-ID: <3FFD01CE.5070301@energyhq.es.eu.org> In-Reply-To: <200401072317.i07NHaM9065411@apollo.backplane.com> References: <200401062000.i06K0hSI012184@dyson.jdyson.com> <200401072317.i07NHaM9065411@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@energyhq.es.eu.org> http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFD01CE.5070301>