FreeBSD cvs-src summary for 18/10/04 to 25/10/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 ============ 5.3-RELEASE branched -------------------- Scott Long (scottl) created the 5.3-RELEASE branch, from which the 5.3 release will be built. 5.3 is scheduled for release tomorrow (October 26th); however, `the schedule`_ is a couple of days behind, so the release may happen around October 28th. The release will be announced on the mailing lists and on the FreeBSD.org Web site. .. _`the schedule`: http://www.freebsd.org/releases/5.3R/schedule.html HighPoint RocketRAID 1820 supported ----------------------------------- Scott Long (scottl) commited a driver called hptmv, for the thrillingly-named `HighPoint RocketRAID 1820`_ series of cards. The 1820 is HighPoint's PCI-X Serial ATA RAID card, supporting RAID 0, 1, 5, and 10 on up to 8 SATA drives. Scott thanks HighPoint for providing the original driver this code is based on, and IronSystems for providing hardware for testing. .. _`HighPoint RocketRAID 1820`: http://www.highpoint-tech.com/USA/sataraid.htm .. _HighPoint: http://www.highpoint-tech.com/ .. _IronSystems: http://www.ironsystems.com/ http://www.freebsd.org/cgi/mid.cgi?200410240537.i9O5bNh3068130 Onboard audio support for UltraSPARC workstations ------------------------------------------------- Pyun YongHyeon (yongari) committed a driver for the onboard CS4231-based audio controller on UltraSPARC workstations. The driver is based on OpenBSD's SBus CS4231 driver, but it has been heavily modified and supports both SBus and EBus. http://www.freebsd.org/cgi/mid.cgi?200410251029.i9PATwhO098396 Major netgraph rework --------------------- Gleb Smirnoff (glebius) committed a major overhaul of parts of the Netgraph code, which allows processing of network packets to be done by a series of arbitrarily-linked nodes. The new code creates a device for each hook on each node, which allows parallel processing. It also enhances performance in reading and writing, adds locking of the device and connection list, and tidies up some style and age problems. http://www.freebsd.org/cgi/mid.cgi?200410182013.i9IKDvcR002883 =============== Notable changes =============== SPECFS removed from the tree ---------------------------- Poul-Henning Kamp (phk) removed SPECFS, which was a layer that handled special device files like the ones in /dev. DEVFS, the device(-file) filesystem, has made it obsolete. Poul-Henning was even moved to poetry by the loss of this dear friend:: Alas, poor SPECFS! -- I knew him, Horatio; A filesystem of infinite jest, of most excellent fancy: he hath taught me lessons a thousand times; and now, how abhorred in my imagination it is! my gorge rises at it. Here were those hacks that I have curs'd I know not how oft. Where be your kludges now? your workarounds? your layering violations, that were wont to set the table on a roar? http://www.freebsd.org/cgi/mid.cgi?200410220959.i9M9xbAl096751 In-kernel TCP socket structure changed -------------------------------------- Andre Oppermann (andre) reduced the size of the tcpcb structure, which means that any programs that use it will have to be recompiled. Users of tcpcb include programs that examine kernel memory for TCP sockets, like sockstat and netstat. http://www.freebsd.org/cgi/mid.cgi?200410221955.i9MJt4Au030816 GENERIC reverted to UP instead of SMP ------------------------------------- Ken Smith (kensmith) switched the GENERIC kernel, which is used by default at installation time, to uniprocessor instead of multiprocessor. A uniprocessor kernel is faster on single-processor systems, which most people use, and safer for installs. Ken also created a configuration file called SMP, which can be used to build multiprocessor kernels out of the box. http://www.freebsd.org/cgi/mid.cgi?200410231958.i9NJwS2I019461 ================= Discussion topics ================= Supporting dynamically-loadable protocols ----------------------------------------- Andre Oppermann (andre) committed support for dynamically loadable protocols. This allows network protocols to be added to and removed from a running kernel. In response to this commit, Sam Leffler (sam) said, "I don't recall seeing this posted anywhere for comment. I have some concerns about this general topic and this code seems incomplete (e.g. I see no locking)." Andre replied, "Locking is not needed because there are no dead moments in transitioning from unregistered to registered and back." He gave a brief technical explanation, asking, "What remaining concerns do you have?" John-Mark Gurney (jmg) replied, "I don't see any GIANT_REQUIRE, or locking around adding a new protocol.. This means there could be a race where two modules loading a protocol get assigned the same slot..." Andre answered, "Luckily loading protocols is a relatively rare occourence and highly unlikely to bite anyone soon. I'll add the giant lock just to be sure as you suggest though." Max Laier (mlaier) also replied to Andre's previous post, saying, "While it is a cool thing to have something like this, but I am afraid that there is code that will trigger problems." He gave an example from the ICMP-handling code, saying, "This is clearly a problem if we can remove protocols. There might be more places where we (temporary) cache values from the protocol array. [ . . . ] I'd suggest, that you remove the possibility to remove protocols completely." He also noted, "[Unloading] has to be handled by the protocol itself." Andre answered, "Ok, this one is easy to fix. I'll audit the code for any other of these abuses." In response to "there might be more places", he said, "From my reading of many parts of the netinet/* code this is usually not a problem and the code is rather well behaved." He answered Max's suggestion that he remove the possibility to remove protocols, saying, "To be able to unload protocols is an important but seldomly used function and it's certainly not that a crash is guarnteed. Far from it." He agreed that a protocol has to handle its own unloading. Julian Elischer (julian) suggested, regarding unloading, "each protocol array entry could have either a mutex or a refcount or both.." A brief discussion followed on the technical details of how a protocol could handle being unloaded. Max replied to Andre's last post, saying, "[The example code was] One of many, I am afraid. '... usually ... rather ...' I really urge you, to reconsider. Many have argumented in the same way. I understand that it is nice to have this possibility, but it *does* cause *real* problems!" He noted, "Divert can be paniced with the sysctl code, btw. [ . . . ] Yes, it is not a problem in the common case, but you have to account for edge cases as well!" Andre replied, asking (WRT "one of many"), "Where are the others?" He suggested, "Unloading a protocol is a very convinient function during prototyping. For the final version you can refuse to unload." In response to Max's "edge case" note, he said, "And you have to account for that unloads do not happen for every packet that goes through the box." Max replied, "We are really concerned that you are introduceing something that is not fully though about. We will have problems with this and I really think that it should be backed out now and fixed before reconsidered! [ . . . ] Claiming that [races] will not be 'most of the time' is not exactly the right approach for serious development." To respond to Andre's request for specifics, he offered, "ip_encap is going to be a lot of fun. And that's just the most obvious, I could find." He also replied to Andre's final comment, saying, "The fact that an unload happens very seldom, is not an excuse to allow it to panic the box." Andre answered, "Dynamically registering and unregistering is not the problem. [ . . . ] What can be problematic is not the unregistering of an protocol but the subsequent unloading of the module that implemented said protocol. [ . . . ] In the case of IPDIVERT I made it unloadable and as you correctly say there can be certain race conditions. The solution is not to back out what I committed but to make IPDIVERT to refuse to unload, *or* to fix IPDIVERT in a way to make it 100% race safe to unload." In response to the ip_encap comment, he said, "You are on the wrong boat here. ip_encap is an entirely different animal. [ . . . ] And to rebut that I have carelessly thrown some untested and immature piece of code in there; I have in fact looked and thought through this and studied the code that uses it." Harti Brandt (harti) replied to Andre's earlier "this one is easy to fix" post, saying, "Actually it is not easy to fix. Even if you don't introduce a temporary variable the compiler can and probably will still use a temporary copy of the function pointer. You cannot prevent the compiler from makeing temporary copies." Dag-Erling Smorgrav (des) responded, "Yes, you can, using the volatile keyword." Harti replied, "That doesn't help you if the compiler needs to fetch the function pointer into a register to call it. That would be allowed even if you declare the pointer volatile." He gave an example to illustrate his point. Sam posted a reply to Andre's first post, explaining that he had been away for the day. "It seems many people have responded though not addressing all my concerns. While I applaud your effort to attack this problem I must say I am totally disgusted by the way in which you've dropped this code in the tree with no review or opportunity for comment." http://www.freebsd.org/cgi/mid.cgi?200410191513.i9JFDUbf072176 ================= Committer changes ================= Andrew Reiter (arr) has returned to committerhood after ten months away. http://www.freebsd.org/cgi/mid.cgi?200410222154.i9MLsXwC041321 =============== Other bug fixes =============== Lukas Ertl (le) fixed a locking bug in the NDIS code that could cause system panics. The bug and fix were submitted by Frank Mayhar in `PR 72795`_. .. _`PR 72795`: http://www.freebsd.org/cgi/query-pr.cgi?pr=72795 http://www.freebsd.org/cgi/mid.cgi?200410182133.i9ILXvsN012113 John-Mark Gurney (jmg) fixed a problem with the de driver, which supports DEC DC21x4x Ethernet cards, that would cause it to get very slow after a few minutes of use. http://www.freebsd.org/cgi/mid.cgi?200410182306.i9IN6DDx016512Received on Mon Oct 25 2004 - 19:43:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:19 UTC