From owner-freebsd-current@FreeBSD.ORG Wed Dec 24 09:19:14 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FE9F16A4CE; Wed, 24 Dec 2003 09:19:13 -0800 (PST) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D7243D50; Wed, 24 Dec 2003 09:18:55 -0800 (PST) (envelope-from wegster@mindcore.net) Received: from mindcore.net (rdu162-234-100.nc.rr.com [24.162.234.100]) hBOHIcov020755; Wed, 24 Dec 2003 12:18:53 -0500 (EST) Message-ID: <3FE9CA6E.4060902@mindcore.net> Date: Wed, 24 Dec 2003 12:18:38 -0500 From: Scott W User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <3FE93499.7060307@freebsd.org> In-Reply-To: <3FE93499.7060307@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-current@freebsd.org Subject: Re: Plans for 5.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2003 17:19:14 -0000 Scott Long wrote: > All, > > FreeBSD 5.2 is pretty much wrapped up and ready to ship. The only thing > that remains is a week or so of community testing and QA on RC2 so that > we can catch any serious/obvious bugs. For those of you who are looking > to the future, we still have a lot of work to do in order for 5.3 to be > the 5-STABLE branchpoint. > > A year ago I started working on the 5-STABLE roadmap with the hope of > gently guiding development towards the areas that needed attention. So > far, it seems to have worked out pretty well; many of the items that I > listed in the first and seconds drafts of the document have been > addressed thanks to the hard work of many people. However, there are > still a number of items that need to be addressed. Depending on the > success of 5.2 and the immediate work that happens in the next month, > I'd like to schedule 5.3 to be released in late April or early May. The > possiblity exists of slipping into June, but if we wait any later than > that then we risk loosing momentum and credibility. The next 4 weeks > are critical to the momentum of the project and the ability to meet the > release deadline. > > The things that need to happen in the next 4 weeks include: > > - Import a newer binutils package so that TLS work can start. David > O'brien is the traditional toolchain person. It would be good to get > a few other people involved with this so that David doesn't keep > burning out. > > - Figure out the plan for a newer GDB that supports all of our Tier-1 > platforms and can be extended to support KSE debugging. A lot of > people have discussed this and I welcome more open discussion on it. > > - Start work on making interrupts faster. There are two areas to > consider: > - Machine dependent optimizations to speed up interrupt servicing, > along with optimizing context switching for ithreads. Peter Wemm > and Bosko Milekic have talked about this, and there might even be > some prototype code hanging around in the Perforce repo. > - Devise a two-tier interrupt servicing approach where drivers can > register both a fast-path filter and/or a normal ithread handler. > I've talked about doing this and expanding it to also support new > interrupt architectures like MSI. > If the first approach can be prototyped and proven to work well, then > there might not be a need for the second approach. However, it is > imperative that interrupts be made faster for 5.3; we still suffer a > signficant performance impact in the storage and network areas due to > high interrupt latency. Both approaches are discussed in detail in > the 5-STABLE roadmap document. > > - Make ULE be the default scheduler. This is a 'dogfood' item in that > by making it the default early on, hopefully bugs can be found and > addressed quickly. Jeff Roberson is the ULE person and has been very > responsive to bug reports. > > - Make KSE be the default thread library. There are a number of facets > to consider: > - Alpha and sparc64 _STILL_ lack working KSE support. We have been > committed to KSE long enough that all architectures need to come on > board. Any architecture that does not have working KSE support when > we enter 5-STABLE risks a loss of viability. Marcel Moolenar and > Jeff Roberson have talked about what needs to be done for these > platforms. > - Many ports still check for pthreads support incorrectly. We need to > decide exactly what compiler options, library names, etc, will be > used to specify pthreads and KSE, and then fix the broken ports. > - Again, this is a 'dogfood' item. We need as much testing as > possible so that bugs can be weeded out. KSE has made incredible > progress in the past year and is nearing production quality; we need > to just give it the final push. David Xu and Dan Eischen have been > the primary KSE engineer for the past year and are also very > responsive to bug reports. > > - Start pushing socket locking changes into the tree. Along with this, > we need to devise a strategy to allow the lesser-used protocol stacks > (netatalk, netipx, etc) to not be orphaned by this move. Sam Leffler > is the primary engineer here. > > Again, these are all changes that lay a foundation for us to be > successful with 5.3. Other features that we need for 5.3 include: > > - BIND9. This was discussed extensively at the last DevSummit. We need > to start putting this plan into action. Doug Barton is the primary > BIND person but has limited time at the moment due to moving and > changing jobs. I'm sure that he would appreciate help with this task. > > - More Giant pushdown. Seemingly simple devices like ps/2 mice and > keyboards are suffering from being under Giant. I've started work on > making these particular drivers be MPSAFE, but there are many more > that need to be tackled. VM lockdown also needs to progress further. > Alan Cox is doing an excellent job at this. > One area that is falling behind in the lockdown effort is CAM. Justin > Gibbs and I have been discussing this and believe that the best > approach is to move the probe/discovery code into a kthread. Once > that is done, locking of the rest of CAM should be straight-forward. > > - Stability. We suffered a lot of stability regressions in the late > summer and fall of 2003 and are only now starting to recover. > Problems with ATAng persist, as do problems with the new interrupt > routing code. John Baldwin is extremely responsive to bug reports > regarding interrupt routing, so the best way to help is to load > FreeBSD onto as many systems as you can and report problems back to > him. > > > This mostly sums up what remains on the 5-STABLE roadmap. If there are > any new items that I've forgotten, please let me know. A detailed 5.3 > TODO list will be published on the website once 5.2 is out the door. I > welcome open discussion on all of this. > > Thanks! > > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Scott- this is somewhat off-topic, but does this mean that plans for creating the 5-STABLE label are not going to happen at 5.2-RELEASE, but instead at 5.3-RELEASE? Sorry if I missed this being mentioned somewhere, but last I saw was 5-STABLE at the release of 5.2 (or close to)...? Thanks, Scott