Plans for 5.3

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