FreeBSD cvs-src summary for 16/08/04 to 23/08/04 ++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. This newsletter is marked up in reStructuredText_, so any odd punctuation that you see is likely intended for the reST parser. .. _reStructuredText: http://docutils.sourceforge.net/rst.html You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). If you would like to get the summary without subscribing to current_at_, please send mail to freebsd-cvs-summary-subscribe_at_lists.enderunix.org. Thanks to Omer Faruk Sen and EnderUNIX for hosting this list. For Lukasz Dudek and Szymon Roczniak's Polish translations of these summaries, which may lag the English ones slightly, please see http://mocart.pinco.pl/FreeBSD/. .. contents:: ============ New features ============ RELENG_5 branched; HEAD becomes 6-CURRENT ----------------------------------------- Two small commits by Scott Long (scottl) this week marked two major, connected events in FreeBSD's history. A new branch, RELENG_5, was created, marking the transition of FreeBSD 5 to "stable" status. This "stable" tag means that 5.x releases will become the new production FreeBSD releases. This is the first new stable branch since RELENG_4 was branched in March 2000, marking the start of the 4.x branch. The second commit changed the major number of the CVS HEAD from 5 to 6. -CURRENT FreeBSD now uses the major number 6, the first new major number since March 2000. This will be the new development branch, leading towards the eventual release of FreeBSD 6.0. Thank you and congratulations to all the FreeBSD contributors! Rather than mention all the roles and teams that make the project work, I highly recommend you read the `Contributors to FreeBSD`_ article. .. _`Contributors to FreeBSD`: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/ http://www.freebsd.org/cgi/mid.cgi?200408180004.i7I04m3h019649 http://www.freebsd.org/cgi/mid.cgi?200408180021.i7I0LCCK020175 Rewritten floppy driver ----------------------- Poul-Henning Kamp (phk) committed a rewrite of the floppy driver, making it work with GEOM and not require the Giant system lock in SMP systems. The new driver also fixes some bugs in the old code and adds some new features, like sysctl tunables for many drive-related parameters. http://www.freebsd.org/cgi/mid.cgi?200408201514.i7KFEP5S025188 make universe now parallelizable -------------------------------- Ruslan Ermilov (ru) enhanced make universe, the Makefile target that builds world for all the architectures, to be able to build the worlds in parallel. He gives the following examples of how to use the new build method:: make universe Builds worlds sequentially, each world sequentially. make universe JFLAG=-j4 Builds worlds sequentially, each world in parallel. make -j4 universe make -j4 universe JFLAG=-j2 Builds four worlds in parallel, each world will be built in parallel too. World parallelization is set to four in the first synopsis, and to two in the second. make -j4 universe JFLAG=-B Builds worlds in parallel, each world sequentially. http://www.freebsd.org/cgi/mid.cgi?200408180717.i7I7H1cD032867 =============== Notable changes =============== ipfw converted to use PFIL_HOOKS -------------------------------- Andre Oppermann (andre) converted ipfw to use the PFIL_HOOKS packet filter API. This doesn't change the use or ABI of ipfw, but it does mean that the PFIL_HOOKS kernel option is required to use the IPFIREWALL option. http://www.freebsd.org/cgi/mid.cgi?200408172205.i7HM5sDs087606 Netgraph made 64-bit ready -------------------------- Julian Elischer (julian) committed code to align the Netgraph message fields so it will work on 64-bit machines. This change requires a recompile of any code that uses Netgraph. http://www.freebsd.org/cgi/mid.cgi?200408200124.i7K1ONcF095627 ================= Discussion topics ================= The meaning of MFC ------------------ In Julian Elischer (julian)'s commit described in `Netgraph made 64-bit ready`_, he noted, "MFC after: 2 days". Ruslan Ermilov (ru) replied, "We need to be careful with using "MFC" now. What does it mean, RELENG_5, RELENG_4, or both? ;)" Ken Smith (kensmith) followed up, "This problem will continue for a while too unfortunately. :-(". He clarified, "shortly after the 5.X release RELENG_5 becomes -stable. HEAD as always will be -current. But RELENG_4 will still be an active development branch and the target of at least some normal developer-generated commits until we release 4.11. After 4.11 is released the current plan is to turn over RELENG_4 (as well as RELENG_4_11) to so_at_ and it becomes an Errata Branch." Eivind Eklund (eivind) answered, "I suggest replacing "MFC" with 'MT4' (merge to 4.x) and 'MT5' (merge to 5) for the case where we are indicating planned merges." Ruslan pointed out, "Changing to this would lose the 'from' information, which is quite useful, as we sometimes merge not only from -CURRENT." He suggested the format "MFC [into <branch>] (after|in):". Eivind clarified, "I meant for the markers we put into the commit messages for the reminder script, and that's explictly from the branch the change is commited to." Regarding Ruslan's suggestion, he said, "I see some slight disadvantages: It is more to type, and it include information (that this is -current) that is both unnecessary (it is known from the ids) and may be wrong if we change release engineering practices." M. Warner Losh (imp) also replied to Ken's post, noting, "Of course MFC After just generates email to the person doing the commit as a reminder." http://www.freebsd.org/cgi/mid.cgi?200408200124.i7K1ONcF095627 Handling routing message overflows ---------------------------------- Robert Watson (rwatson) made a commit allowing the size of the routing message queue to be set with the sysctl net.route.netisr_maxqlen. He mentioned, "Default the maximum depth to 256 rather than IFQ_MAXLEN due to the downsides of dropping routing messages." Andre Oppermann (andre) replied, "A rtmessage should never ever be dropped. That would wedge the synchronized state of any userland routing daemons." Peter Grehan (grehan) noted, "That only works with infinite memory or if you can flow-control the sources of the messages." Robert also answered Andre's post, saying, "That as may be, but we've always been able to drop them [ . . . ] as we're often unable to block when such a message is generated." He asked, "Do you have any measurement of how deep that socket buffer gets in practice on high volume routers?" Brooks Davis (brooks) suggested, "It might be useful to add a RTM_FOOBAR (or similar :-) message to send when we are forced to drop a message." http://www.freebsd.org/cgi/mid.cgi?200408212120.i7LLK6YQ092852 =================== Important bug fixes =================== Security hole in lukemftpd fixed -------------------------------- David O'Brien (obrien) imported an updated version of lukemftpd, fixing a remotely-exploitable `security hole`_. Since lukemftpd isn't compiled or used in a default install, FreeBSD isn't generally vulnerable to this hole. The only release including lukemftpd was 4.7; even in 4.7, though, it was not enabled by default. .. _`security hole`: ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-009.txt.asc http://www.freebsd.org/cgi/mid.cgi?200408180629.i7I6Tmm2030721 =============== Other bug fixes =============== Robert Watson (rwatson) fixed a bug that was causing "out of data" warnings on large UDP packets sent over the loopback interface. http://www.freebsd.org/cgi/mid.cgi?200408220132.i7M1WnMB001137 Maxime Henrion (mux) fixed a bug in the lnc driver for AMD Lance/PCnet Ethernet cards. This corrects a problem with network support in VMware. http://www.freebsd.org/cgi/mid.cgi?200408222301.i7MN1Epo048916Received on Tue Aug 24 2004 - 13:41:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:08 UTC