Scott Long posted an email to -current detailing his plans for 5.3 development. He explains:
"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."
From: Scott Long [email blocked] To: freebsd-current Subject: Plans for 5.3 Date: Tue, 23 Dec 2003 23:39:21 -0700 rv:1.5) Gecko/20031007 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