Re: Plans for 5.3

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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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