cvs-src summary for October 18-25

From: Mark Johnston <mjohnston_at_skyweb.ca>
Date: Mon, 25 Oct 2004 16:43:53 -0500
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.i9IN6DDx016512
Received 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