Plans for 5.3
Scott W
wegster at mindcore.net
Wed Dec 24 09:19:14 PST 2003
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
More information about the freebsd-current
mailing list