os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add the Jan-Feb 2004 status report

Browse source
This commit is contained in:
Scott Long 2004-03-17 18:08:15 +00:00
parent d6d4d1568c
commit d0a1259007
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=20352
4 changed files with 1740 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

3
en/news/status/Makefile
View file

@ -1,4 +1,4 @@
# $FreeBSD: www/en/news/status/Makefile,v 1.21 2003/10/09 06:12:34 scottl Exp $
# $FreeBSD: www/en/news/status/Makefile,v 1.22 2004/01/28 19:14:40 scottl Exp $
.if exists(../Makefile.conf)
.include "../Makefile.conf"
@ -25,6 +25,7 @@ DATA+= report-nov-2002-dec-2002.html
DATA+= report-jan-2003-feb-2003.html
DATA+= report-mar-2003-sep-2003.html
DATA+= report-oct-2003-dec-2003.html
DATA+= report-jan-2004-feb-2004.html
# Install a sample <project> entry.
DATA+= report-sample.xml

865
en/news/status/report-2004-01-2004-02.xml Normal file
View file

@ -0,0 +1,865 @@
<!-- $FreeBSD$ -->
<report>
<date>
<month>January-February</month>
<year>2004</year>
</date>
<section>
<title>Introduction:</title>
<p>2004 started with another exciting two months for the project.
FreeBSD 5.2 was released in early January and then quickly followed
in February with the 5.2.1 bug-fix release. Looking forward, we
are expecting a late-April release date for FreeBSD 4.10, and
mid-summer date for FreeBSD 5.3. And don't forget to support the
FreeBSD vendors and developers by buying a copy of the latest CD
or DVD sets.</p>
<p>Thanks,</p>
<p>Scott Long</p>
</section>
<project>
<title>Disk and device I/O</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>In the overall area of disk and device I/O, a significant
milestone was reached with the implementation of proper
reference counting on dev_t. We are now able to properly
allocate and free dev_t. Cloning device drivers also had
the job made easier for them with the addition of the unit
number management routines.</p>
<p>It is not quite decided which will be the next step in
the quest for a truly SMPng I/O subsystem, but a leading
candidate is to implement the device-access vnode bypass
to get more concurrency in the system: Instead of taking
the tour through the vnodes for each i/o operation on a
device we will go directly from the file descriptor layer to
DEVFS/SPECFS. In addition to Giant-less disk I/O,
this should enable us to pull the entire tty subsystem
and the PTY driver out from under Giant and we expect that
to improve the "snappiness" of the system measurably.</p>
</body>
</project>
<project>
<title>The FreeBSD Dutch Documentation Project.</title>
<contact>
<person>
<name>
<given>Remko</given>
<common>Lodder</common>
</name>
<email>remko@elvandar.org</email>
</person>
</contact>
<body>
<p>The Dutch Documentation Project is a ongoing project in
translating the handbook and other documentation to the dutch
language. Currently there is 1 active person (me) translating the
documentation. I am currently working on the handbook/basics
section. But i can use some more hands, please drop me an email if
you wish to help out so that the dutch translation will speed up
and be ready in some time. Contact remko@elvandar.org for
information.</p>
</body>
</project>
<project>
<title>Weekly cvs-src summaries</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Johnston</common>
</name>
<email>mark@xl0.org</email>
</person>
</contact>
<links>
<url href="http://excel.xl0.org/FreeBSD/" />
<url href="http://mocart.pinco.pl/FreeBSD/">Polish translations</url>
</links>
<body>
<p>I have been producing weekly summaries of commits and the
surrounding discussions as reported on the cvs-src mailing list.
These summaries are posted to -current on Sunday evenings and
archived on the Web. The reception has been overwhelmingly good.
As of the end of February, Polish translations are being produced
by Lukasz Dudek and Szymon Roczniak; they are also
planning to translate the older summaries.</p>
</body>
</project>
<project>
<title>libarchive/bsdtar</title>
<contact>
<person>
<name>
<given>Tim</given>
<common>Kientzle</common>
</name>
<email>kientzle@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~kientzle/"/>
</links>
<body>
<p>libarchive, with complete documentation, has been committed to
-CURRENT. bsdtar should follow soon. For a few months, gtar
and bsdtar will both be available in the base system. Once
bsdtar is in the tree, I hope to resume work on libpkg and my
pkg_add rewrite.</p>
<p>Note that bsdtar is not an exact replacement for gtar: it does
some things better (reads/writes standard formats, archive ACLs
and file flags, detects format and compression automatically),
some things worse (does not handle multi-volume archives or
sparse files) and a few things just different (writes POSIX-format
archives by default, not GNU-format). The command lines are
sufficiently similar that most users should have no problems
with the transition. However, people who rely on peculiar
options or capabilities of gtar may have to look to ports.</p>
</body>
</project>
<project>
<title>Network interface naming changes</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>The first actual feature related to the if_xname conversion was
committed in early February. Network interfaces can now be
renamed with "ifconfig &lt;if&gt; name &lt;newname&gt;".</p>
<p>Work is slowly progressing on a new network interface cloning API
to enable interesting cloners like auto-configurating vlans.
This work is taking place in the perforce repository under:
//depot/user/brooks/xname/...</p>
</body>
</project>
<project>
<title>PowerPC Port</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Grehan</common>
</name>
<email>grehan@FreeBSD.org</email>
</person>
</contact>
<body>
<p>After a slow time at the end of last year due to a disk crash,
the project is moving along rapidly. The loader is fully
functional with Forth support. Syscons has been integrated.
New Powerbook models are supported. Work is starting on a
G5 port.</p>
<p>There's still lots to do, so as usual volunteers are most
welcome.</p>
</body>
</project>
<project>
<title>The FreeBSD Simplified Chinese Project</title>
<contact>
<person>
<name>
<given>Dong</given>
<common>LI</common>
</name>
<email>ld@FreeBSD.org.cn</email>
</person>
<person>
<name>
<given>Xin</given>
<common>LI</common>
</name>
<email>delphij@frontfree.net</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org.cn">The FreeBSD Simplified
Chinese Project (In Simplified Chinese)</url>
<url href="http://www.freebsd.org.cn/snap/zh_CN/">Translated
Website Snapshot</url>
<url href="http://www.freebsd.org.cn/snap/doc/zh_CN.GB2312/books/handbook/">Translated Handbook Snapshot</url>
</links>
<body>
<p>The project is a joint effort of volunteers, which focus in
the internationalization and localization of the FreeBSD
Operating System and applications running on FreeBSD. All of the
work resulted in this project will be contributed back to the
FreeBSD project.</p>
<p>Thanks to many volunteers' help, by this time of writing, we
have finished more than 60% of the translation of the FreeBSD
Handbook. We plan to submit a preliminary translation of the
FreeBSD website as well as the FreeBSD Handbook when most part of
them were finished, which is expected to happen in a couple of
months. The snapshot of the documentation translation effort
could be accessed through the URL listed above.</p>
<p>The project also supported individual efforts on porting
applications (especially software that supports Simplified
and/or Traditional Chinese) to FreeBSD. We are also doing some
research on making FreeBSD kernel and base system more
i18n-aware.</p>
</body>
</project>
<project>
<title>Verify source reachability option for ipfw2</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff"/>
</links>
<body>
<p>The verify source reachability option for ipfw2 checks if the
source IP address of a packet entering the machine is reachable
at all. Thus if we can't send a packet back because we don't
have a route back we don't have to forward it because two way
communication isn't possible anyway. It is more than likely
that such a packet is spoofed. This option is almost the same as
what is known on Cisco IOS as "ip verify unicast source
reachable-via [any|ifn]". Using this option only makes sense
when you don't have a default route which naturally always
matches. So this is useful for machines acting as routers with
a default-free view of the entire Internet as common when running
a BGP daemon (Zebra/Quagga or OpenBSD bgpd).</p>
<p>One useful way of enabling it globally on a router looks like
this: ipfw add xxxx deny ip from any to any not versrcreach or for
an individual interface only: ipfw add xxxx deny ip from any to
any not versrcreach recv fxp0</p>
</body>
</project>
<project>
<title>Move ARP out of routing table</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The ARP IP address to MAC address mapping does not belong into
the routing table (FIB) as it is currently done. This will move
it to its own hash based structure which will be instantiated
per each 802.1 broadcast domain. With this change it is possible
to have more than one interface in the same IP subnet and layer 2
broadcast domain. The ARP handling and the routing table will be
quite a bit simplified afterwards. As an additional benefit full
MAC address based accosting will be provided. Work on this
project is already in progress.</p>
</body>
</project>
<project>
<title>Automatic sizing of TCP send buffers</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The current TCP send and receive buffers are static and set to a
conservative value to preserve kernel memory. This is sub-optimal
for connections with a high bandwidth*delay product because the
size of the TCP send buffer determines how big the send window
can get. For high bandwidth trans-continental links this seriously
limits the maximum transfer speed per TCP connection. For example
a 170ms RTT and a 32kB send buffer limit the speed to approximately
1.5Mbit per second even thought you might have a 10Mbit pipe.</p>
<p>This project makes the TCP send buffer to automatically adapt to
the optimal buffer size for maximal link usage. In the case
above this would be a buffer of approximately 220kB. The main
challenge is to have a stable and reliable measurement of the link
parameters and manage the kernel memory properly and in a fair way.
We don't want to have a few connections to monopolize all available
socket buffer space and many edge cases have to be considered. The
first implementation will be tuned conservatively but even that
will provide significantly better performance than the static
buffers currently. Work on this project is already in
progress.</p>
</body>
</project>
<project>
<title>Testbed for testing and qualification of TCP performance</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The TCP performance test and qualification testbed is an automated
environment that simulates various common and uncommon end-to-end
network and link characteristics such as delay, bandwidth
limitations, congestion, packet drops, packet corruption and out
of order arrival. The testbed automatically steps through all
link types and tests various TCP optimizations and parameter
adjustments. In the end all data is graphically arranged and
compared against standard behaviour and each other to judge the
positive or negative effects of the modifications. Work on this
project has just started and is based on FreeBSDs dummynet.</p>
</body>
</project>
<project>
<title>FreeBSD ports monitoring system</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Linimon</common>
</name>
<email>linimon_at_lonesome_dot_com</email>
</person>
</contact>
<links>
<url href="http://portsmon.firepipe.net/index.html">
FreeBSD ports monitoring system</url>
</links>
<body>
<p>Thanks to the loan of a box by Will Andrews, the system has
been moved into production. The previous installation
at lonesome.com now refers you to the new system. As part of
the installation, a preliminary
<url href="http://portsmon.firepipe.net/faq.html">FAQ</url> was
added.</p>
<p>The database is updated once per hour.</p>
<p>New reports available include ones about ports marked DEPRECATED,
since that function has now been incorporated into bsd.port.mk.
(The author hopes that this will allow the port deprecation process
to be much more visible to the general FreeBSD user community.) In
addition, a report for ports marked FORBIDDEN was added (the code
was essentially the same).</p>
<p>The next topic of interest is to try to identify ports which are
slave ports because the status of these ports is not currently
being updated automatically. This problem also affects
FreshPorts. PR ports/63683 is an attempt to address this problem.
Also, preliminary work has been done on creating some graphs and
charts for various statistics, and in creating a tool to browse
port dependencies for the entire ports tree.</p>
<p>Some general observations about the trends in ports PRs can be
made:
<ul>
<li>In the past 6 months, the amount of time to get ports PRs
committed has dropped dramatically. (This is especially
true of PRs for new ports.)</li>
<li>The queue of PRs for existing ports that are unmaintained
has similarly been trimmed. Both of these two items are due
in large part to a few very active committers (how do they
ever get their "real" work done?) Thanks, guys, you know who
you are.</li>
<li>There is still a fairly high number of PRs (~400/~750) which
apply to existing ports, and have been assigned to a FreeBSD
committer. This represents around 370 individual ports. We
seem to have a much harder time getting these numbers to go
down; basically, we just hold our own most weeks. This is
somewhat disappointing.</li>
<li>The number of ports marked BROKEN has jumped dramatically,
currently standing at over 250 (for i386-current). This
represents less a sudden problem as it does Kris' effort to
bring existing brokenness to people's attention -- thus, a
much larger percentage of ports with build errors are now
labeled as BROKEN.</li>
<li>Approximately two-thirds of the port build errors are still
due to compilation problems, primarily from the gcc3.3 import.
Another 10% fail to install correctly. The reasons for the
others are more varied.</li>
</ul>
</p>
</body>
</project>
<project>
<title>FreeSBIE</title>
<contact>
<person>
<name>
<given>FreeSBIE</given>
<common>Staff</common>
</name>
<email>staff@FreeSBIE.org</email>
</person>
</contact>
<links>
<url href="http://www.freesbie.org">FreeSBIE Home</url>
<url href="mailto:freesbie@gufi.org">FreeSBIE Mailing
List</url>
<url href="http://www.freesbie.org/?section=mirror-en">FreeSBIE
Mirror List</url>
</links>
<body>
<p>The FreeSBIE Project aims to develop a set of scripts that allow
anyone to create their own FreeBSD Bootable Cdrom, with their own
set of installed packages. The Project releases an ISO builded
with FreeSBIE scripts, to show what they can do. On Sunday 29
February 2004, FreeSBIE 1.0 was released and it had a great
success, as there were post on Slashdot.org, OSnews, DaemonNews
and BSDForums. Thanks to the huge amount of feedback they got,
FreeSBIE Developers are now developing new features such as
support for archs different from i386. Website redesign is on the
way too.</p>
</body>
</project>
<project>
<title>kgi4BSD</title>
<contact>
<person>
<name>
<given>Nicholas</given>
<common>Souchu</common>
</name>
<email>nsouch@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~nsouch/kgi4BSD"> Project URL</url>
</links>
<body>
<p>Move to Perforce is done. I spent some time on building a
common compilation tree with Linux: until now drivers were
build in a FreeBSD makefile tree, not compatible with Linux.</p>
<p>The next priorities are ANSI support and keymaps in the
KGC Kernel Graphic Console system.</p>
</body>
</project>
<project>
<title>FreeBSD/ia64</title>
<contact>
<person>
<name>
<given>Marcel</given>
<common>Moolenaar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/platforms/ia64/index.html">
Home page.</url>
</links>
<body>
<p>Work on the PMAP overhaul has been put into gear. A lot of issues
will be addressed, including support for sparse physical memory
and of course SMP. Performance will be addressed to the extend
possible, but functionality has priority. The redesign will lay
the foundation for NUMA support where possible. An example of this
is limiting TLB shootdowns to processors that actually have or had
TLBs belonging to the PMAP loaded. Of course, without NUMA
hardware the implementation of NUMA support is quite limited.</p>
</body>
</project>
<project>
<title>FreeBSD Package Grid</title>
<contact>
<person>
<name>
<given>Kris</given>
<common>Kennaway</common>
</name>
<email>kris@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Distributed package builds are currently done using a set of
home-grown shell scripts for managing, scheduling and
dispatching of package builds on the client machines. This has
been sufficient for our needs in the past, but has a number of
significant shortcomings that limit future growth. I am
rewriting the package build scripts to work on top of Sun
GridEngine (ports/sysutils/sge), as a client application of a
"FreeBSD package grid". Some of the design goals for the new
system are:</p>
<ul>
<li>Better robustness against machine failure, and more efficient
scheduling of build jobs</li>
<li>Support for remote build machines, to make better use of machine
resources and clusters that are not on the same LAN as the
build master</li>
<li>Ability for other committers to submit port build jobs to the
system, for testing of changes, new ports, etc.</li>
</ul>
</body>
</project>
<project>
<title>vinum + GEOM</title>
<contact>
<person>
<name>
<given>Lukas</given>
<common>Ertl</common>
</name>
<email>le@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://mailbox.univie.ac.at/~le/geom_vinum.tar.gz" />
</links>
<body>
<p>The "geomification" of vinum has made some progress. I now have
all basic setups working (concatenated plexes, striped plexes,
RAID5 plexes, and RAID1), but I still have to implement correct
error handling and status change handling.</p>
<p>Still missing is a userland tool, so currently you still have to
use "old-style" vinum to configure your setup.</p>
</body>
</project>
<project>
<title>NanoBSD</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>NanoBSD, src/tools/tools/nanobsd, is a tool for stuffing FreeBSD
onto small disk media (like CompactFlash) for embedded
applications. The disk image is built with three partitions, two
for software images and one for configuration files. Having two
software partitions means that new software can be uploaded to the
non-active partition while running off the active partition.</p>
<p> The first really public version has been committed and many
suggestions and offers of patches have started pouring in.</p>
</body>
</project>
<project>
<title>Porting OpenBSD's pf</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>max@love2party.net</email>
</person>
<person>
<name>
<given>Pyun</given>
<common>YongHyeon</common>
</name>
<email>yongari@kt-is.co.kr</email>
</person>
</contact>
<links>
<url href="http://pf4freebsd.love2party.net/" />
<url href="http://www.benzedrine.cx/pf.html">PF homepage</url>
<url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url>
<url href="http://www.rofug.ro/projects/freebsd-altq/">ALTQ</url>
</links>
<body>
<p>The sources were imported from OpenBSD 3.4R and patched with
diffs obtained from the port. Since March the 8th it is linked
to the build and install. There is some more work to be done in
order make pf a home inside the tree, but the biggest hunk of
work was lifted during the past two month.</p>
<p>OpenBSD 3.5 is scheduled for early May, so we might see an update
before 5.3R. Work towards integration of the - often requested
- ALTQ framework is in progress also, though it is not yet clear
how well it goes along with the ongoing work towards a giant free
net stack.</p>
</body>
</project>
<project>
<title>FreeBSD/arm Status Report</title>
<contact>
<person>
<name>
<given>Olivier</given>
<common>Houchard</common>
</name>
<email>cognet@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Development goes reasonably fast, right now it boots single user.
It is still very simics-centric, and it deserves a huge cleanup
and a few bug fixes, but there's already a decent amount of code
to work with, mostly taken from NetBSD. I now plan to work on real
hardware support (as soon as I can get some), to get the missing
userland bits (mainly rtld and the pthread libs) so that I can
build a full world.</p>
</body>
</project>
<project>
<title>SGI XFS port for FreeBSD</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Kabaev</common>
</name>
<email>kan@FreeBSD.org</email>
</person>
<person>
<name>
<given>Russell</given>
<common>Cattelan</common>
</name>
<email>cattelan@thebarn.com</email>
</person>
</contact>
<body>
<p>Not much has changed since last report was submitted. The
read-onle access XFS volumes is quite stable now. The work is
underway to rewrite xfs_buf layer to minimize local changes
intrusiveness. Initial attempt to make XFS code to compile and
run on amd64 is in progress too.</p>
<p>We really need a care-taker for our userland tools.</p>
</body>
</project>
<project>
<title>Compile FreeBSD with Intels C compiler (icc)</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Leidinger</common>
</name>
<email>netchild@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.Leidinger.net/FreeBSD/">Some patches.</url>
</links>
<body>
<p>If nothing bad happened, the icc patches got committed around
the date of the deadline for submissions of this report. Please
search the archives of -current and/or cvs-all for more
information.</p>
<p>The next steps in this project are to
<ul>
<li>fix the kernel to also run without problems when compiled
with icc v8</li>
<li>fix the kernel if some problems surface after more people
give it a try</li>
<li>get some ports to compile with icc</li>
</ul>
</p>
</body>
</project>
<project>
<title>
Bluetooth stack for FreeBSD (Netgraph implementation)
</title>
<contact>
<person>
<name>
<given>Maksim</given>
<common>Yevmenkin</common>
</name>
<email>m_evmenkin@yahoo.com</email>
</person>
</contact>
<body>
<p>Not much to report. Bluetooth Service Discovery Procotol daemon
sdpd was integrated with existing Bluetooth utilities. From now
on users should not use GNU sdpd (Linux BlueZ port).</p>
<p>Bluetooth HID profile implementation is almost complete. Thanks
to Matt Peterson &lt; matt at peterson dot org &gt; for giving me
Bluetooth keyboard and mouse for development.</p>
</body>
</project>
<project>
<title>FreeBSD GNOME Project Report</title>
<contact>
<person>
<name>
<given>FreeBSD</given>
<common>GNOME Team</common>
</name>
<email>gnome@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
Site.</url>
</links>
<body>
<p>It has been a year since our last status report, but we
haven't slowed down. Since the last report, Alexander
Nedotsukov (bland) and Pav Lucistnik (pav) have joined the
FreeBSD GNOME team. GNOME 2.4 was released back in September
2003, followed by 2.4.1 and 2.4.2. We are actively working on
getting GNOME 2.6.0 out the door at the end of March. GNOME 2.6
Beta releases can be obtained via the project URL above.</p>
<p>To help make GNOME 2.6.0 our best release to date, we have
created a script to automate the upgrade from GNOME 2.4. We
also have a new GNOME
<url href="http://www.marcuscom.com/tinderbox/">package build
server</url>
that builds and serves i386 packages for all supported FreeBSD
releases. We plan on having the GNOME 2.6.0 packages available
the moment 2.6.0 hits the ports tree.</p>
<p>Included in the release of GNOME 2.6 is GTK+ 2.4, the next
installment in the GTK+ 2 series. Because GTK+ 2 has become
very stable over the past few years, the FreeBSD GNOME Team is
pushing for GTK+ 2 support to be included by default in all
applications that support it. This has already been done with
Mozilla, Firefox, and Thunderbird. A complete GNOME Desktop and
application environment can already be built using only GTK+ 2.
The ultimate goal is to phase GTK+ 1 out of the ports tree.</p>
</body>
</project>
<project>
<title>Network Stack Locking</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>This project is aimed at converting the FreeBSD network stack from
running under the single Giant kernel lock to permitting it to
run in a fully parallel manner on multiple CPUs (i.e., a fully
threaded network stack). This will improve performance/latency
through reentrancy and preemption on single-processor machines,
and also on multi-processor machines by permitting real
parallelism in the processing of network traffic. As of FreeBSD
5.2, it was possible to run low level network functions, as well
as the IP filtering and forwarding plane, without the Giant lock,
as well as "process to completion" in the interrupt handler.</p>
<p>Work continues to improve the maturity and completeness of
the locking (and performance) of the network stack for 5.3. The
network stack locking development branch has been updated cothe
latest CVS HEAD, tracking a variety of FreeBSD changes, including
tracking and driving changes in the interface and device cloning
APIs, push-down and fixes to locking in the Berkeley Packet
Filter, consistency improvements in allocation flags for network
objects, diagnosis of excessive acquisition of Giant in various
system callouts and timeouts, removal of Giant from several
system callouts, "const"-ification of a number of global
variables in the network stack (IPv4, IPv6, elsewhere) as part of
ananalysis of locking requirements, fine-grain locking of a
number of pseudo-interfaces (disc, loopback, faith, stf, gif, tap,
tun), IP encapsulation and tunneling, initial review and locking
of parts of PPP and SLIP, experimentation with PCB assertions on
IPv6, additional socket locking assertions, graphing of the FreeBSD
sockets layer to support locking analysis, merging of theMT_TAG to
m_tag conversion to improve the ability to queue packets, moving
of the debug.mpsafenet tunable to controlling Giant over the
forwarding plane to Giant over the entire stack("dual-mode" to
support non-MPSAFE protocols), adaption of existing network lock
assertions to also assert Giant when running non-MPSAFE, analysis
of high cost of select() locking, improved locking and
synchronization annotations, TCP callouts run MPSAFE, logtimeout()
runs MPSAFE, uma_timeout() runs MPSAFE, callout sampling
instrumentation, loadav() runs MPSAFE, AppleTalk locking begun:
AARP locked down and DDP analysis, rawcb list locked, locking
analysis of mrouter and IP ID code, IGMP locked, IPv6 analysis
begun, IPX/SPX analysis begun, PPP timeouts converted to callouts,
Netgraph analysis begun. Many of these changes have not yet been
merged to the main FreeBSDtree, but this is a work in progress.</p>
<p>In related work on Pipe IPC (not quite network stack locking),
substantial time was invested in diagnosing an increase in the
cost of pipe allocation since FreeBSD 4.x, as well as coalescing
the several allocations needed to create a pipe, as well as moving
to slab allocation so as to amortize the cost of pipe
initialization. Future work here will include caching the VM
structures supporting pipe buffers.</p>
<p>Recent contributors include Robert Watson, Sam Leffler, MaxLaier,
Maurycy Pawlowski-Wieronski, Brooks Davis, and many others who are
omitted here only by accident.</p>
</body>
</project>
</report>

865
en/news/status/report-jan-2004-feb-2004.xml Normal file
View file

@ -0,0 +1,865 @@
<!-- $FreeBSD$ -->
<report>
<date>
<month>January-February</month>
<year>2004</year>
</date>
<section>
<title>Introduction:</title>
<p>2004 started with another exciting two months for the project.
FreeBSD 5.2 was released in early January and then quickly followed
in February with the 5.2.1 bug-fix release. Looking forward, we
are expecting a late-April release date for FreeBSD 4.10, and
mid-summer date for FreeBSD 5.3. And don't forget to support the
FreeBSD vendors and developers by buying a copy of the latest CD
or DVD sets.</p>
<p>Thanks,</p>
<p>Scott Long</p>
</section>
<project>
<title>Disk and device I/O</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>In the overall area of disk and device I/O, a significant
milestone was reached with the implementation of proper
reference counting on dev_t. We are now able to properly
allocate and free dev_t. Cloning device drivers also had
the job made easier for them with the addition of the unit
number management routines.</p>
<p>It is not quite decided which will be the next step in
the quest for a truly SMPng I/O subsystem, but a leading
candidate is to implement the device-access vnode bypass
to get more concurrency in the system: Instead of taking
the tour through the vnodes for each i/o operation on a
device we will go directly from the file descriptor layer to
DEVFS/SPECFS. In addition to Giant-less disk I/O,
this should enable us to pull the entire tty subsystem
and the PTY driver out from under Giant and we expect that
to improve the "snappiness" of the system measurably.</p>
</body>
</project>
<project>
<title>The FreeBSD Dutch Documentation Project.</title>
<contact>
<person>
<name>
<given>Remko</given>
<common>Lodder</common>
</name>
<email>remko@elvandar.org</email>
</person>
</contact>
<body>
<p>The Dutch Documentation Project is a ongoing project in
translating the handbook and other documentation to the dutch
language. Currently there is 1 active person (me) translating the
documentation. I am currently working on the handbook/basics
section. But i can use some more hands, please drop me an email if
you wish to help out so that the dutch translation will speed up
and be ready in some time. Contact remko@elvandar.org for
information.</p>
</body>
</project>
<project>
<title>Weekly cvs-src summaries</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Johnston</common>
</name>
<email>mark@xl0.org</email>
</person>
</contact>
<links>
<url href="http://excel.xl0.org/FreeBSD/" />
<url href="http://mocart.pinco.pl/FreeBSD/">Polish translations</url>
</links>
<body>
<p>I have been producing weekly summaries of commits and the
surrounding discussions as reported on the cvs-src mailing list.
These summaries are posted to -current on Sunday evenings and
archived on the Web. The reception has been overwhelmingly good.
As of the end of February, Polish translations are being produced
by Lukasz Dudek and Szymon Roczniak; they are also
planning to translate the older summaries.</p>
</body>
</project>
<project>
<title>libarchive/bsdtar</title>
<contact>
<person>
<name>
<given>Tim</given>
<common>Kientzle</common>
</name>
<email>kientzle@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~kientzle/"/>
</links>
<body>
<p>libarchive, with complete documentation, has been committed to
-CURRENT. bsdtar should follow soon. For a few months, gtar
and bsdtar will both be available in the base system. Once
bsdtar is in the tree, I hope to resume work on libpkg and my
pkg_add rewrite.</p>
<p>Note that bsdtar is not an exact replacement for gtar: it does
some things better (reads/writes standard formats, archive ACLs
and file flags, detects format and compression automatically),
some things worse (does not handle multi-volume archives or
sparse files) and a few things just different (writes POSIX-format
archives by default, not GNU-format). The command lines are
sufficiently similar that most users should have no problems
with the transition. However, people who rely on peculiar
options or capabilities of gtar may have to look to ports.</p>
</body>
</project>
<project>
<title>Network interface naming changes</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>The first actual feature related to the if_xname conversion was
committed in early February. Network interfaces can now be
renamed with "ifconfig &lt;if&gt; name &lt;newname&gt;".</p>
<p>Work is slowly progressing on a new network interface cloning API
to enable interesting cloners like auto-configurating vlans.
This work is taking place in the perforce repository under:
//depot/user/brooks/xname/...</p>
</body>
</project>
<project>
<title>PowerPC Port</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Grehan</common>
</name>
<email>grehan@FreeBSD.org</email>
</person>
</contact>
<body>
<p>After a slow time at the end of last year due to a disk crash,
the project is moving along rapidly. The loader is fully
functional with Forth support. Syscons has been integrated.
New Powerbook models are supported. Work is starting on a
G5 port.</p>
<p>There's still lots to do, so as usual volunteers are most
welcome.</p>
</body>
</project>
<project>
<title>The FreeBSD Simplified Chinese Project</title>
<contact>
<person>
<name>
<given>Dong</given>
<common>LI</common>
</name>
<email>ld@FreeBSD.org.cn</email>
</person>
<person>
<name>
<given>Xin</given>
<common>LI</common>
</name>
<email>delphij@frontfree.net</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org.cn">The FreeBSD Simplified
Chinese Project (In Simplified Chinese)</url>
<url href="http://www.freebsd.org.cn/snap/zh_CN/">Translated
Website Snapshot</url>
<url href="http://www.freebsd.org.cn/snap/doc/zh_CN.GB2312/books/handbook/">Translated Handbook Snapshot</url>
</links>
<body>
<p>The project is a joint effort of volunteers, which focus in
the internationalization and localization of the FreeBSD
Operating System and applications running on FreeBSD. All of the
work resulted in this project will be contributed back to the
FreeBSD project.</p>
<p>Thanks to many volunteers' help, by this time of writing, we
have finished more than 60% of the translation of the FreeBSD
Handbook. We plan to submit a preliminary translation of the
FreeBSD website as well as the FreeBSD Handbook when most part of
them were finished, which is expected to happen in a couple of
months. The snapshot of the documentation translation effort
could be accessed through the URL listed above.</p>
<p>The project also supported individual efforts on porting
applications (especially software that supports Simplified
and/or Traditional Chinese) to FreeBSD. We are also doing some
research on making FreeBSD kernel and base system more
i18n-aware.</p>
</body>
</project>
<project>
<title>Verify source reachability option for ipfw2</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff"/>
</links>
<body>
<p>The verify source reachability option for ipfw2 checks if the
source IP address of a packet entering the machine is reachable
at all. Thus if we can't send a packet back because we don't
have a route back we don't have to forward it because two way
communication isn't possible anyway. It is more than likely
that such a packet is spoofed. This option is almost the same as
what is known on Cisco IOS as "ip verify unicast source
reachable-via [any|ifn]". Using this option only makes sense
when you don't have a default route which naturally always
matches. So this is useful for machines acting as routers with
a default-free view of the entire Internet as common when running
a BGP daemon (Zebra/Quagga or OpenBSD bgpd).</p>
<p>One useful way of enabling it globally on a router looks like
this: ipfw add xxxx deny ip from any to any not versrcreach or for
an individual interface only: ipfw add xxxx deny ip from any to
any not versrcreach recv fxp0</p>
</body>
</project>
<project>
<title>Move ARP out of routing table</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The ARP IP address to MAC address mapping does not belong into
the routing table (FIB) as it is currently done. This will move
it to its own hash based structure which will be instantiated
per each 802.1 broadcast domain. With this change it is possible
to have more than one interface in the same IP subnet and layer 2
broadcast domain. The ARP handling and the routing table will be
quite a bit simplified afterwards. As an additional benefit full
MAC address based accosting will be provided. Work on this
project is already in progress.</p>
</body>
</project>
<project>
<title>Automatic sizing of TCP send buffers</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The current TCP send and receive buffers are static and set to a
conservative value to preserve kernel memory. This is sub-optimal
for connections with a high bandwidth*delay product because the
size of the TCP send buffer determines how big the send window
can get. For high bandwidth trans-continental links this seriously
limits the maximum transfer speed per TCP connection. For example
a 170ms RTT and a 32kB send buffer limit the speed to approximately
1.5Mbit per second even thought you might have a 10Mbit pipe.</p>
<p>This project makes the TCP send buffer to automatically adapt to
the optimal buffer size for maximal link usage. In the case
above this would be a buffer of approximately 220kB. The main
challenge is to have a stable and reliable measurement of the link
parameters and manage the kernel memory properly and in a fair way.
We don't want to have a few connections to monopolize all available
socket buffer space and many edge cases have to be considered. The
first implementation will be tuned conservatively but even that
will provide significantly better performance than the static
buffers currently. Work on this project is already in
progress.</p>
</body>
</project>
<project>
<title>Testbed for testing and qualification of TCP performance</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The TCP performance test and qualification testbed is an automated
environment that simulates various common and uncommon end-to-end
network and link characteristics such as delay, bandwidth
limitations, congestion, packet drops, packet corruption and out
of order arrival. The testbed automatically steps through all
link types and tests various TCP optimizations and parameter
adjustments. In the end all data is graphically arranged and
compared against standard behaviour and each other to judge the
positive or negative effects of the modifications. Work on this
project has just started and is based on FreeBSDs dummynet.</p>
</body>
</project>
<project>
<title>FreeBSD ports monitoring system</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Linimon</common>
</name>
<email>linimon_at_lonesome_dot_com</email>
</person>
</contact>
<links>
<url href="http://portsmon.firepipe.net/index.html">
FreeBSD ports monitoring system</url>
</links>
<body>
<p>Thanks to the loan of a box by Will Andrews, the system has
been moved into production. The previous installation
at lonesome.com now refers you to the new system. As part of
the installation, a preliminary
<url href="http://portsmon.firepipe.net/faq.html">FAQ</url> was
added.</p>
<p>The database is updated once per hour.</p>
<p>New reports available include ones about ports marked DEPRECATED,
since that function has now been incorporated into bsd.port.mk.
(The author hopes that this will allow the port deprecation process
to be much more visible to the general FreeBSD user community.) In
addition, a report for ports marked FORBIDDEN was added (the code
was essentially the same).</p>
<p>The next topic of interest is to try to identify ports which are
slave ports because the status of these ports is not currently
being updated automatically. This problem also affects
FreshPorts. PR ports/63683 is an attempt to address this problem.
Also, preliminary work has been done on creating some graphs and
charts for various statistics, and in creating a tool to browse
port dependencies for the entire ports tree.</p>
<p>Some general observations about the trends in ports PRs can be
made:
<ul>
<li>In the past 6 months, the amount of time to get ports PRs
committed has dropped dramatically. (This is especially
true of PRs for new ports.)</li>
<li>The queue of PRs for existing ports that are unmaintained
has similarly been trimmed. Both of these two items are due
in large part to a few very active committers (how do they
ever get their "real" work done?) Thanks, guys, you know who
you are.</li>
<li>There is still a fairly high number of PRs (~400/~750) which
apply to existing ports, and have been assigned to a FreeBSD
committer. This represents around 370 individual ports. We
seem to have a much harder time getting these numbers to go
down; basically, we just hold our own most weeks. This is
somewhat disappointing.</li>
<li>The number of ports marked BROKEN has jumped dramatically,
currently standing at over 250 (for i386-current). This
represents less a sudden problem as it does Kris' effort to
bring existing brokenness to people's attention -- thus, a
much larger percentage of ports with build errors are now
labeled as BROKEN.</li>
<li>Approximately two-thirds of the port build errors are still
due to compilation problems, primarily from the gcc3.3 import.
Another 10% fail to install correctly. The reasons for the
others are more varied.</li>
</ul>
</p>
</body>
</project>
<project>
<title>FreeSBIE</title>
<contact>
<person>
<name>
<given>FreeSBIE</given>
<common>Staff</common>
</name>
<email>staff@FreeSBIE.org</email>
</person>
</contact>
<links>
<url href="http://www.freesbie.org">FreeSBIE Home</url>
<url href="mailto:freesbie@gufi.org">FreeSBIE Mailing
List</url>
<url href="http://www.freesbie.org/?section=mirror-en">FreeSBIE
Mirror List</url>
</links>
<body>
<p>The FreeSBIE Project aims to develop a set of scripts that allow
anyone to create their own FreeBSD Bootable Cdrom, with their own
set of installed packages. The Project releases an ISO builded
with FreeSBIE scripts, to show what they can do. On Sunday 29
February 2004, FreeSBIE 1.0 was released and it had a great
success, as there were post on Slashdot.org, OSnews, DaemonNews
and BSDForums. Thanks to the huge amount of feedback they got,
FreeSBIE Developers are now developing new features such as
support for archs different from i386. Website redesign is on the
way too.</p>
</body>
</project>
<project>
<title>kgi4BSD</title>
<contact>
<person>
<name>
<given>Nicholas</given>
<common>Souchu</common>
</name>
<email>nsouch@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~nsouch/kgi4BSD"> Project URL</url>
</links>
<body>
<p>Move to Perforce is done. I spent some time on building a
common compilation tree with Linux: until now drivers were
build in a FreeBSD makefile tree, not compatible with Linux.</p>
<p>The next priorities are ANSI support and keymaps in the
KGC Kernel Graphic Console system.</p>
</body>
</project>
<project>
<title>FreeBSD/ia64</title>
<contact>
<person>
<name>
<given>Marcel</given>
<common>Moolenaar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/platforms/ia64/index.html">
Home page.</url>
</links>
<body>
<p>Work on the PMAP overhaul has been put into gear. A lot of issues
will be addressed, including support for sparse physical memory
and of course SMP. Performance will be addressed to the extend
possible, but functionality has priority. The redesign will lay
the foundation for NUMA support where possible. An example of this
is limiting TLB shootdowns to processors that actually have or had
TLBs belonging to the PMAP loaded. Of course, without NUMA
hardware the implementation of NUMA support is quite limited.</p>
</body>
</project>
<project>
<title>FreeBSD Package Grid</title>
<contact>
<person>
<name>
<given>Kris</given>
<common>Kennaway</common>
</name>
<email>kris@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Distributed package builds are currently done using a set of
home-grown shell scripts for managing, scheduling and
dispatching of package builds on the client machines. This has
been sufficient for our needs in the past, but has a number of
significant shortcomings that limit future growth. I am
rewriting the package build scripts to work on top of Sun
GridEngine (ports/sysutils/sge), as a client application of a
"FreeBSD package grid". Some of the design goals for the new
system are:</p>
<ul>
<li>Better robustness against machine failure, and more efficient
scheduling of build jobs</li>
<li>Support for remote build machines, to make better use of machine
resources and clusters that are not on the same LAN as the
build master</li>
<li>Ability for other committers to submit port build jobs to the
system, for testing of changes, new ports, etc.</li>
</ul>
</body>
</project>
<project>
<title>vinum + GEOM</title>
<contact>
<person>
<name>
<given>Lukas</given>
<common>Ertl</common>
</name>
<email>le@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://mailbox.univie.ac.at/~le/geom_vinum.tar.gz" />
</links>
<body>
<p>The "geomification" of vinum has made some progress. I now have
all basic setups working (concatenated plexes, striped plexes,
RAID5 plexes, and RAID1), but I still have to implement correct
error handling and status change handling.</p>
<p>Still missing is a userland tool, so currently you still have to
use "old-style" vinum to configure your setup.</p>
</body>
</project>
<project>
<title>NanoBSD</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>NanoBSD, src/tools/tools/nanobsd, is a tool for stuffing FreeBSD
onto small disk media (like CompactFlash) for embedded
applications. The disk image is built with three partitions, two
for software images and one for configuration files. Having two
software partitions means that new software can be uploaded to the
non-active partition while running off the active partition.</p>
<p> The first really public version has been committed and many
suggestions and offers of patches have started pouring in.</p>
</body>
</project>
<project>
<title>Porting OpenBSD's pf</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>max@love2party.net</email>
</person>
<person>
<name>
<given>Pyun</given>
<common>YongHyeon</common>
</name>
<email>yongari@kt-is.co.kr</email>
</person>
</contact>
<links>
<url href="http://pf4freebsd.love2party.net/" />
<url href="http://www.benzedrine.cx/pf.html">PF homepage</url>
<url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url>
<url href="http://www.rofug.ro/projects/freebsd-altq/">ALTQ</url>
</links>
<body>
<p>The sources were imported from OpenBSD 3.4R and patched with
diffs obtained from the port. Since March the 8th it is linked
to the build and install. There is some more work to be done in
order make pf a home inside the tree, but the biggest hunk of
work was lifted during the past two month.</p>
<p>OpenBSD 3.5 is scheduled for early May, so we might see an update
before 5.3R. Work towards integration of the - often requested
- ALTQ framework is in progress also, though it is not yet clear
how well it goes along with the ongoing work towards a giant free
net stack.</p>
</body>
</project>
<project>
<title>FreeBSD/arm Status Report</title>
<contact>
<person>
<name>
<given>Olivier</given>
<common>Houchard</common>
</name>
<email>cognet@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Development goes reasonably fast, right now it boots single user.
It is still very simics-centric, and it deserves a huge cleanup
and a few bug fixes, but there's already a decent amount of code
to work with, mostly taken from NetBSD. I now plan to work on real
hardware support (as soon as I can get some), to get the missing
userland bits (mainly rtld and the pthread libs) so that I can
build a full world.</p>
</body>
</project>
<project>
<title>SGI XFS port for FreeBSD</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Kabaev</common>
</name>
<email>kan@FreeBSD.org</email>
</person>
<person>
<name>
<given>Russell</given>
<common>Cattelan</common>
</name>
<email>cattelan@thebarn.com</email>
</person>
</contact>
<body>
<p>Not much has changed since last report was submitted. The
read-onle access XFS volumes is quite stable now. The work is
underway to rewrite xfs_buf layer to minimize local changes
intrusiveness. Initial attempt to make XFS code to compile and
run on amd64 is in progress too.</p>
<p>We really need a care-taker for our userland tools.</p>
</body>
</project>
<project>
<title>Compile FreeBSD with Intels C compiler (icc)</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Leidinger</common>
</name>
<email>netchild@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.Leidinger.net/FreeBSD/">Some patches.</url>
</links>
<body>
<p>If nothing bad happened, the icc patches got committed around
the date of the deadline for submissions of this report. Please
search the archives of -current and/or cvs-all for more
information.</p>
<p>The next steps in this project are to
<ul>
<li>fix the kernel to also run without problems when compiled
with icc v8</li>
<li>fix the kernel if some problems surface after more people
give it a try</li>
<li>get some ports to compile with icc</li>
</ul>
</p>
</body>
</project>
<project>
<title>
Bluetooth stack for FreeBSD (Netgraph implementation)
</title>
<contact>
<person>
<name>
<given>Maksim</given>
<common>Yevmenkin</common>
</name>
<email>m_evmenkin@yahoo.com</email>
</person>
</contact>
<body>
<p>Not much to report. Bluetooth Service Discovery Procotol daemon
sdpd was integrated with existing Bluetooth utilities. From now
on users should not use GNU sdpd (Linux BlueZ port).</p>
<p>Bluetooth HID profile implementation is almost complete. Thanks
to Matt Peterson &lt; matt at peterson dot org &gt; for giving me
Bluetooth keyboard and mouse for development.</p>
</body>
</project>
<project>
<title>FreeBSD GNOME Project Report</title>
<contact>
<person>
<name>
<given>FreeBSD</given>
<common>GNOME Team</common>
</name>
<email>gnome@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
Site.</url>
</links>
<body>
<p>It has been a year since our last status report, but we
haven't slowed down. Since the last report, Alexander
Nedotsukov (bland) and Pav Lucistnik (pav) have joined the
FreeBSD GNOME team. GNOME 2.4 was released back in September
2003, followed by 2.4.1 and 2.4.2. We are actively working on
getting GNOME 2.6.0 out the door at the end of March. GNOME 2.6
Beta releases can be obtained via the project URL above.</p>
<p>To help make GNOME 2.6.0 our best release to date, we have
created a script to automate the upgrade from GNOME 2.4. We
also have a new GNOME
<url href="http://www.marcuscom.com/tinderbox/">package build
server</url>
that builds and serves i386 packages for all supported FreeBSD
releases. We plan on having the GNOME 2.6.0 packages available
the moment 2.6.0 hits the ports tree.</p>
<p>Included in the release of GNOME 2.6 is GTK+ 2.4, the next
installment in the GTK+ 2 series. Because GTK+ 2 has become
very stable over the past few years, the FreeBSD GNOME Team is
pushing for GTK+ 2 support to be included by default in all
applications that support it. This has already been done with
Mozilla, Firefox, and Thunderbird. A complete GNOME Desktop and
application environment can already be built using only GTK+ 2.
The ultimate goal is to phase GTK+ 1 out of the ports tree.</p>
</body>
</project>
<project>
<title>Network Stack Locking</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>This project is aimed at converting the FreeBSD network stack from
running under the single Giant kernel lock to permitting it to
run in a fully parallel manner on multiple CPUs (i.e., a fully
threaded network stack). This will improve performance/latency
through reentrancy and preemption on single-processor machines,
and also on multi-processor machines by permitting real
parallelism in the processing of network traffic. As of FreeBSD
5.2, it was possible to run low level network functions, as well
as the IP filtering and forwarding plane, without the Giant lock,
as well as "process to completion" in the interrupt handler.</p>
<p>Work continues to improve the maturity and completeness of
the locking (and performance) of the network stack for 5.3. The
network stack locking development branch has been updated cothe
latest CVS HEAD, tracking a variety of FreeBSD changes, including
tracking and driving changes in the interface and device cloning
APIs, push-down and fixes to locking in the Berkeley Packet
Filter, consistency improvements in allocation flags for network
objects, diagnosis of excessive acquisition of Giant in various
system callouts and timeouts, removal of Giant from several
system callouts, "const"-ification of a number of global
variables in the network stack (IPv4, IPv6, elsewhere) as part of
ananalysis of locking requirements, fine-grain locking of a
number of pseudo-interfaces (disc, loopback, faith, stf, gif, tap,
tun), IP encapsulation and tunneling, initial review and locking
of parts of PPP and SLIP, experimentation with PCB assertions on
IPv6, additional socket locking assertions, graphing of the FreeBSD
sockets layer to support locking analysis, merging of theMT_TAG to
m_tag conversion to improve the ability to queue packets, moving
of the debug.mpsafenet tunable to controlling Giant over the
forwarding plane to Giant over the entire stack("dual-mode" to
support non-MPSAFE protocols), adaption of existing network lock
assertions to also assert Giant when running non-MPSAFE, analysis
of high cost of select() locking, improved locking and
synchronization annotations, TCP callouts run MPSAFE, logtimeout()
runs MPSAFE, uma_timeout() runs MPSAFE, callout sampling
instrumentation, loadav() runs MPSAFE, AppleTalk locking begun:
AARP locked down and DDP analysis, rawcb list locked, locking
analysis of mrouter and IP ID code, IGMP locked, IPv6 analysis
begun, IPX/SPX analysis begun, PPP timeouts converted to callouts,
Netgraph analysis begun. Many of these changes have not yet been
merged to the main FreeBSDtree, but this is a work in progress.</p>
<p>In related work on Pipe IPC (not quite network stack locking),
substantial time was invested in diagnosing an increase in the
cost of pipe allocation since FreeBSD 4.x, as well as coalescing
the several allocations needed to create a pipe, as well as moving
to slab allocation so as to amortize the cost of pipe
initialization. Future work here will include caching the VM
structures supporting pipe buffers.</p>
<p>Recent contributors include Robert Watson, Sam Leffler, MaxLaier,
Maurycy Pawlowski-Wieronski, Brooks Davis, and many others who are
omitted here only by accident.</p>
</body>
</project>
</report>

9
en/news/status/status.sgml
View file

@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD: www/en/news/status/status.sgml,v 1.16 2003/10/09 12:55:26 scottl Exp $">
<!ENTITY date "$FreeBSD: www/en/news/status/status.sgml,v 1.17 2004/01/28 19:14:40 scottl Exp $">
<!ENTITY title "FreeBSD Status Reports">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
]>
@ -30,6 +30,13 @@
<p>These status reports may be reproduced in whole or in part, as long as the
source is clearly identified and appropriate credit given. </p>
<h2>2004</h2>
<ul>
<li><a href="report-jan-2004-feb-2004.html">January, 2004 -
February, 2004 </a></li>
</ul>
<h2>2003</h2>
<ul>