Roadmap for FreeBSD 5.3

Freebird

FreeBSD Release Engineering Team's Scott Long has outlined future plans for FreeBSD 5.3 now that FreeBSD 5.2-RC2 is getting close to release quality.

[Read more]
-------------------------------------
Date: Tue, 23 Dec 2003 23:39:21 -0700
From: Scott Long <scottl@freebsd.org>
To: freebsd-current@freebsd.org
Subject: 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