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

Clean up the status reports so that the format makes sense.

Browse source
This commit is contained in:
Brad Davis 2007-04-11 06:13:30 +00:00
parent 3b19e730b9
commit ecf0561164
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=29993
32 changed files with 65 additions and 40725 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
en/news/status/Makefile
View file

@ -1,4 +1,4 @@
# $FreeBSD: www/en/news/status/Makefile,v 1.36 2007/01/16 22:50:46 mlaier Exp $
# $FreeBSD: www/en/news/status/Makefile,v 1.37 2007/04/10 03:35:31 brd Exp $
.if exists(../Makefile.conf)
.include "../Makefile.conf"
@ -9,33 +9,33 @@
DOCS= status.sgml
XMLDOCS= report-june-2001
XMLDOCS+= report-july-2001
XMLDOCS+= report-august-2001
XMLDOCS+= report-september-2001
XMLDOCS+= report-november-2001
XMLDOCS+= report-dec-2001-jan-2002
XMLDOCS+= report-feb-2002-apr-2002
XMLDOCS+= report-may-2002-june-2002
XMLDOCS+= report-july-2002-aug-2002
XMLDOCS+= report-sept-2002-oct-2002
XMLDOCS+= report-nov-2002-dec-2002
XMLDOCS+= report-jan-2003-feb-2003
XMLDOCS+= report-mar-2003-sep-2003
XMLDOCS+= report-oct-2003-dec-2003
XMLDOCS+= report-jan-2004-feb-2004
XMLDOCS+= report-mar-2004-apr-2004
XMLDOCS+= report-may-2004-june-2004
XMLDOCS+= report-july-2004-dec-2004
XMLDOCS+= report-jan-2005-mar-2005
XMLDOCS+= report-mar-2005-june-2005
XMLDOCS+= report-july-2005-oct-2005
XMLDOCS+= report-oct-2005-dec-2005
XMLDOCS+= report-jan-2006-mar-2006
XMLDOCS+= report-apr-2006-jun-2006
XMLDOCS+= report-june-2006-oct-2006
XMLDOCS+= report-oct-2006-dec-2006
XMLDOCS+= report-2007-jan-2007-mar
XMLDOCS= report-2001-06
XMLDOCS+= report-2001-07
XMLDOCS+= report-2001-08
XMLDOCS+= report-2001-09
XMLDOCS+= report-2001-11
XMLDOCS+= report-2001-12-2002-01
XMLDOCS+= report-2002-02-2002-04
XMLDOCS+= report-2002-05-2002-06
XMLDOCS+= report-2002-07-2002-08
XMLDOCS+= report-2002-09-2002-10
XMLDOCS+= report-2002-11-2002-12
XMLDOCS+= report-2003-01-2003-02
XMLDOCS+= report-2003-03-2003-09
XMLDOCS+= report-2003-10-2003-12
XMLDOCS+= report-2004-01-2004-02
XMLDOCS+= report-2004-03-2004-04
XMLDOCS+= report-2004-05-2004-06
XMLDOCS+= report-2004-07-2004-12
XMLDOCS+= report-2005-01-2005-03
XMLDOCS+= report-2005-03-2005-06
XMLDOCS+= report-2005-07-2005-10
XMLDOCS+= report-2005-10-2005-12
XMLDOCS+= report-2006-01-2006-03
XMLDOCS+= report-2006-04-2006-06
XMLDOCS+= report-2006-06-2006-10
XMLDOCS+= report-2006-10-2006-12
XMLDOCS+= report-2007-01-2007-03
XSLT.DEFAULT= report.xsl

4
en/news/status/README
View file

@ -51,7 +51,7 @@ Compiling status reports - best practices
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status
Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/README,v 1.2 2007/04/09 06:45:39 brd Exp $ -->
<!-- $FreeBSD: www/en/news/status/README,v 1.3 2007/04/10 16:01:01 brd Exp $ -->
<report>
<date>
<month>July-September</month>
@ -149,7 +149,7 @@ Report//EN"
<title>June-October, 2006 Status Report</title>
<p>The June-October, 2006 Status Report is <a
href="&base;/news/status/report-june-2006-oct-2006.html">now
href="&base;/news/status/report-2006-06-2006-10.html">now
available</a> with 49 entries.</p>
</event>

2546
en/news/status/report-2006-10-2005-12.xml
View file

File diff suppressed because it is too large Load diff

1117
en/news/status/report-2007-jan-2007-mar.xml
View file

File diff suppressed because it is too large Load diff

2141
en/news/status/report-apr-2006-jun-2006.xml
View file

File diff suppressed because it is too large Load diff

1523
en/news/status/report-august-2001.xml
View file

File diff suppressed because it is too large Load diff

721
en/news/status/report-dec-2001-jan-2002.xml
View file

@ -1,721 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-dec-2001-jan-2002.xml,v 1.7 2004/04/07 11:27:47 phantom Exp $ -->
<report>
<date>
<month>December 2001 - January 2002</month>
<year></year> <!-- XXX -->
</date>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
$FreeBSD: www/en/news/status/report-dec-2001-jan-2002.xml,v 1.7 2004/04/07 11:27:47 phantom Exp $
</cvs:keyword>
</cvs:keywords>
<section>
<title>Introduction</title>
<p>This bi-monthly report covers development activities on the FreeBSD
Project for December 2001 and January 2002. A variety of
accomplishments have been made over the last couple of months,
including strong progress relating to the KSE project, which
brings Scheduler Activations to the FreeBSD kernel, as well
as less visible infrastructure projects such as improvements
to the mount interface, PAM integration work, and translation
efforts. Shortly following the deadline for this status
report, the BSD Conference and FreeBSD Developer Summit were
held, and will be covered in the next bi-monthly report at
the end of March. Plans are already under way for the USENIX
Annual Technical Conference in Monterey, CA, later this year,
and all and sundry are encouraged to attend to get further
insight in FreeBSD development.</p>
<p>Robert Watson</p>
</section>
<project>
<title>USB stack maintenance</title>
<contact>
<person>
<name>
<given>Josef</given>
<common>Karthauser</common>
</name>
<email>joe@FreeBSD.org</email>
</person>
</contact>
<body>
<p>I've been working to integrate recent improvements in the
NetBSD usb stack to FreeBSD -current. Both NetBSD and OpenBSD
currently share the same source, as FreeBSD did too at once point
before it diverged. The goal is to get back to that state, but
there are many improvements on both sides that need to be merged
before this is complete.</p>
<p>I'm currently looking for someone to help maintain usb in
-stable. Please let me know if you're interested.</p>
</body>
</project>
<project>
<title>TrustedBSD ACLs</title>
<contact>
<person>
<name>
<given>Chris</given>
<common>Faulhaber</common>
</name>
<email>jedgar@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.fxp.org/jedgar/ACL/">
</url>
</links>
<body>
<p>Patches for cp(1), ls(1), and mv(1) to bring in
POSIX.1e-compliant Access Control List support have been updated
to patch against builds of -CURRENT. Other system utilities are
currently being evaluated for ACL support including install(1)
(patch available) and mtree(8). Work is in progress to verify the
native getfacl(1), setfacl(1), and other utilities build and work
correctly on other ACL-enabled systems (e.g. Linux w/ACL patches)
and to help verify POSIX-compliance of the continuing TrustedBSD
work along with other systems. Finally, experimental Perl and PHP
modules are available allowing limited access to native ACLs for
languages other than C.</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>
<links>
</links>
<body>
<p>The project is making progress. The goal is to design and
implement Host Controller Interface (HCI) and Link Layer Control
and Adaptation Protocol (L2CAP) layers using Netgraph framework.
More distant goal is to write support for Service Discovery
Protocol (SDP) and RFCOMM protocol (Serial port emulation over
Bluetooth link) . All information was obtained from Bluetooth
Specification Book v1.1.</p>
<p>Project status: In progress. 1) Design: mostly complete, there
are some minor issues to be resolved. 2) Implementation: Kernel -
HCI and L2CAP Netgraph nodes have been implemented; 3) User space
(API, library, utilities) - in progress. 4) Testing: In progress.
I do not have real Bluetooth hardware at this point, so i wrote
some tools that allow me to test the code. Some of them will be
used as foundation for future user space utilities.</p>
<p>Issues: 1) Bluetooth hardware; I do not have real Bluetooth
hardware, so if people can donate hardware/specs it would be
great. I promise to write all required drivers and make them
available. I also promise to return hardware/specs on first
request. 2) Project name; I would like to see the name that
reflects the following: it is a Bluetooth stack, implementation
is for FreeBSD and implementation is based on Netgraph
framework</p>
</body>
</project>
<project>
<title>"GEOM" - generalized block storage manipulation</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~phk/Geom/">Old concept paper
here.</url>
</links>
<body>
<p>This project is now finally underway, thanks to DARPA and NAI
getting a sponsorship lined up. The infrastructure code and data
structures are currently taking form inside a userland simulation
harness. Basic MBR and BSD methods have been written and device
attach/taste/dettach algorithms been implemented and
validated.</p>
</body>
</project>
<project>
<title>jp.FreeBSD.org daily SNAPSHOTs project</title>
<contact>
<person>
<name>
<given>Makoto</given>
<common>Matsushita</common>
</name>
<email>matusita@jp.FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://snapshots.jp.FreeBSD.org/">Project
Webpage</url>
<url href="http://www.jp.FreeBSD.org/snapshots/notes.html">
SNAPSHOTs Notes (in Japanese)</url>
</links>
<body>
<p>I've update OS of buildboxes to the latest FreeBSD 5-current
and 4-stable. Everything goes fine. From January 2002, I've
started a webzine, SNAPSHOTS Notes (only Japanese version is
available). SNAPSHOTs Notes pickups tips and information
especially for the people living with FreeBSD 5-current/4-stable.
Article or idea for SNAPSHOTs notes are always welcome (you don't
need to write in Japanese :-).</p>
</body>
</project>
<project>
<title>TrustedBSD Audit</title>
<contact>
<person>
<name>
<given>trustedbsd-discuss</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD project
website</url>
</links>
<body>
<p>Robert Watson created the TrustedBSD audit perforce tree,
which is a branch from the TrustedBSD base tree, in order to
start pushing development efforts towards using a revision
control system. Andrew Reiter started to merge in some framework
related code for generation of audit records, enqueueing writes,
and handling data writing. There is a great deal of work to be
done with updates and discussion on the
trustedbsd-discuss@TrustedBSD.org mailing list.</p>
</body>
</project>
<project>
<title>KSE Status Report</title>
<contact>
<person>
<name>
<given>Julian</given>
<common>Elischer</common>
</name>
<email>julian@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~julian/">Links from
here.</url>
<url href="http://www.FreeBSD.org/~jasone/kse/">Links from
here.</url>
</links>
<body>
<p>The KSE project (an attempt to support scalable thread in
FreeBSD using kernel support), has reached What I call "milestone
3". At this milestone it is possible to run a multithreaded
program on a single CPU but with full concurrency of threads on
that CPU. In other words the kernel supports the fact that one
thread can block by allowing another thread to run in its place.
A test program that demonstrates this is available at the above
website.</p>
<p>Milestone 4 will be to allow threads from the same program to
run on multiple CPUs but may require more input from the SMPng
project. I am at the moment (Feb 6) getting ready to commit a
first set of changes for milestone 3, that have no real effect
but serve to drastically reduce the complexity of the remaining
diff so that others can read it more easily. After changes to
libkvm to support this diff have been added it should be possible
to run 'ps' and look at multiple threads in a treaded process. I
will be demonstrating KSE/M3 at BSDcon.</p>
</body>
</project>
<project>
<title>Netgraph ATM</title>
<contact>
<person>
<name>
<given>Harti</given>
<common>Brandt</common>
</name>
<email>brandt@fokus.gmd.de</email>
</person>
</contact>
<links>
<url
href="ftp://ftp.fokus.gmd.de/pub/cc/cats/usr/harti/ngatm/" />
</links>
<body>
<p>The Netgraph ATM package has been split into a number of
smaller packages: bsnmp is a general-purpose SNMP daemon with
support for loadable modules. Two modules come with it: one
implementing the standard network-interface and IP related parts
of MIB-2 and one for interfacing other modules to the NetGraph
sub-system. ngatmbase contains the drivers for the ATM hardware,
the ng_atm netgraph type and a few test tools. This package
allows one to use ATM PVCs. It should be possible, for example,
to do PPP over ATM with this package. Both bsnmp and ngatmbase
are available in version 1.0 under the link above. Two other
modules will be released in February: ngatmsig containing the
UNI-4.0 signalling stack as netgraph nodes and ngatmip containing
CLIP and LANE-2.0.</p>
</body>
</project>
<project>
<title>FreeBSD C99 &amp; POSIX Conformance Project</title>
<contact>
<person>
<name>
<given>Mike</given>
<common>Barcroft</common>
</name>
<email>mike@FreeBSD.org</email>
</person>
<person>
<name>
<common>FreeBSD-Standards Mailing List</common>
</name>
<email>standards@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~mike/c99/" />
</links>
<body>
<p>A significant amount of progress was made in December and
January, particularly in the area of utility conformance. Several
utilities were updated to conform to SUSv3, they include: at(1),
mailx(1), pwd(1), split(1), and uudecode(1). Several patches have
been submitted to increase conformance in other utilities, they
include: fold(1), patch(1), m4(1), nice(1), pr(1), renice(1),
wc(1), and xargs(1). These are in the process of being reviewed
and committed. Two new utilities have been written, specifically
pathchk(1) and tabs(1). These are also being reviewed and will be
committed shortly.</p>
<p>A patch which implements most of the requirements of scanf(3) is
being reviewed and is expected to be committed shortly. This will
allow us to MFC a number of new functions and headers.
Additionally, work has started on wide string and complex number
support.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project (in
Japanese)</url>
</links>
<body>
<p>For 4.5-RELEASE, port ja-man-doc-4.5.tgz is in sync with base
system except for OpenSSH pages (OpenSSH 2.3 based instead of
2.9) and perl5 pages (jpman project do not maintain). Section 3
updating has 55% finished.</p>
<p>OKAZAKI Tetsurou has incorporated changes on base system's
groff into port japanese/groff. MORI Kouji has fixed two bugs of
port japanese/man.</p>
</body>
</project>
<project>
<title>KAME</title>
<contact>
<person>
<name>
<given>KAME core team</given>
<common>
</common>
</name>
<email>core@kame.net</email>
<name>
<given>KAME Users Mailing List</given>
<common>
</common>
</name>
<email>snap-users@kame.net</email>
</person>
</contact>
<links>
<url href="http://www.kame.net/" />
</links>
<body>
<p>The KAME project is currently focusing on the scoped
addressing architecture, the advanced API implementation, NATPT
and the mobile ipv6 implementation. Though these stuffs are not
stable enough to be merge into the FreeBSD tree, you can get and
try them from the above URL.</p>
</body>
</project>
<project>
<title>FreeBSD in Bulgarian</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Pentchev</common>
</name>
<email>roam@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD-bg.ringlet.net/" />
<url href="http://people.FreeBSD.org/~roam/bg/" />
</links>
<body>
<p>The FreeBSD in Bulgarian project aims to bring a more
comfortable working environment to Bulgarian users of the FreeBSD
OS. This includes, but is not limited to, font, keymap and locale
support, translation of the FreeBSD documentation into Bulgarian,
local user groups and various forms of on-line help channels and
discussion forums to help Bulgarians adopt and use FreeBSD.</p>
<p>A guide for using FreeBSD with Bulgarian settings has been put
up on the project's website. The CVS repository will be made
public shortly, linked to on the URL's above.</p>
<p>An independent project for making FreeBSD easier to use by
Bulgarians has appeared, <a
href="http://www.FreeBSD-bg.org/">http://www.FreeBSD-bg.org/</a>.
It also hosts a mailing list for discussions of FreeBSD in
Bulgarian, <a href="mailto:stable@FreeBSD-bg.org">
stable@FreeBSD-bg.org</a>. For more information about the mailing
list, send an e-mail with "help" in the message body to
<a href="mailto:majordomo@FreeBSD-bg.org">
majordomo@FreeBSD-bg.org</a>.</p>
</body>
</project>
<project>
<title>FreeBSD Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@eyesbeyond.com</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/java" />
</links>
<body>
<p>The past two months have been an exciting time in the FreeBSD
Java Project with the signing of a license between the FreeBSD
Foundation and Sun allowing us access to updated JDK source code
and the Java Compatibility Kit (JCK). This license will also
allow the project to release a binary version of both the JDK and
JRE once JCK testing is complete. Work on this testing is under
way with the project hopeful of being able to make a binary
release in the not too distant future.</p>
<p>In lieu of the binary release which was hoped for with FreeBSD
4.5 the project will release an updated source patchset this
weekend. This patchset will feature further work on the FreeBSD
"native" threads subsystem from Bill Huey. Also, thanks to hard
work by Joe Kelsey and Fuyuhiko Maruyama, the patchset will for
the first time feature a working Java browser plugin!</p>
</body>
</project>
<project>
<title>Revised {mode,log}page support for camcontrol</title>
<contact>
<person>
<name>
<given>Kelly</given>
<common>Yancey</common>
</name>
<email>kbyanc@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Extending camcontrol's page definition file format to include
both modepage and logpage definitions; adding support to
camcontrol to query and reset log page parameters. Consideration
is being made to possibly include support for diagnostic and
vital product data pages, but that is outside the current project
scope. New page definition file format includes capability to
conditionally include page definitions based on SCSI INQUIRY
results allowing vendor-specific pages to be described also.
Approximately 90% complete.</p>
</body>
</project>
<project>
<title>Pluggable Authentication Modules</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Murray</common>
</name>
<email>markm@FreeBSD.org</email>
</person>
<person>
<name>
<given>Dag-Erling</given>
<common>Sm&#248;rgrav</common>
</name>
<email>des@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://openpam.sourceforge.net/">OpenPAM</url>
</links>
<body>
<p>OpenPAM, a new library intended to replace Linux-PAM in
FreeBSD, has been written and is undergoing integration testing.
It is available for download from the URL listed above.</p>
<p>In addition to this, a couple of new modules have been written
(pam_lastlog(8), pam_login_access(8)), and the pam_unix(8) module
has been extended to perform most of the tasks normally performed
by login(1), which is now fully PAMified.</p>
<p>The PAM FDP article has been put on hold until OpenPAM
replaces Linux-PAM in CVS, to avoid wasting effort on soon-to-be
obsolete documentation.</p>
</body>
</project>
<project>
<title>TrustedBSD MAC Implementation</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD Project Web
Site</url>
</links>
<body>
<p>Substantial progress has been made towards a working MAC
implementation. The focus over the last two months has been
moving from a hard-coded series of MAC policies to a more
flexible implementation. A pluggable policy framework has been
created (and is still under development), supporting Biba, MLS,
TE, a "BSD Extended" model, and a sample mac_none module. Some
modules must be compiled in or loaded prior to boot; others may
be introduced at run-time. Support for networking has improved,
with improved handling of IP fragmentation in IPv4, support for
various pseudo-interfaces such as if_tun and if_tap, improved
integration into userland, NFS-related fixes, moving the VFS
enforcement out of individual filesystems, support for a
'multilevel' mount flag, support for explicit labeling in procfs
and devfs, addition of an 'extattrctl lsattr' argument to list
EAs on a filesystem, support for label ranges in the Biba and MAC
policies, and much more.</p>
<p>Targets for the next two months include more universal
enforcement of VFS-related calls, improved support for
alternative ABIs, improved flexibility of in-kernel subject and
object labels, support for IPv6 and IPsec, and improved support
for NFS serving.</p>
<p>Development continues in the FreeBSD Perforce repository,
which may be accessed using cvsup.</p>
</body>
</project>
<project>
<title>New mount(2) API</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
<person>
<name>
<given>Maxime</given>
<common>Henrion</common>
</name>
<email>mux@sneakerz.org</email>
</person>
</contact>
<body>
<p>Now that the patch has been mailed to the
freebsd-arch@FreeBSD.org mailing list, and that there were no
objections, the commit will happen soon. Poul is currently
testing it in his own tree. After it has been committed, it will
be time to modify the filesystems in the tree to use VFS_NMOUNT
instead of VFS_MOUNT. Mount(8) will also need some modifications.
Some new manpages -- nmount(2) and kernel_vmount(9) -- are being
created in the meantime.</p>
</body>
</project>
<project>
<title>SMPng</title>
<contact>
<person>
<name>
<given>smp@FreeBSD.org</given>
</name>
<email>smp@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/smp/">SMPng project
website</url>
</links>
<body>
<p>Alfred Perlstein committed file descriptor locking code
which was definitely a good push towards trying to lock down
some important pieces of global data. Peter Wemm has made
progress on pmap cleanups for x86 SMP TLB shootdowns. Matt
Dillon and John Baldwin have made progress on getting patches
done for moving accesses to ucred's out from under Giant's
protection. John Baldwin has also made some commits in order
to get the alpha port's SMP working. Matt Dillon has plans
for hunting down fileops locking issues in order to continue
his previous Giant pushdown work.</p>
</body>
</project>
</report>

1301
en/news/status/report-feb-2002-apr-2002.xml
View file

File diff suppressed because it is too large Load diff

704
en/news/status/report-jan-2003-feb-2003.xml
View file

@ -1,704 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-jan-2003-feb-2003.xml,v 1.5 2004/04/04 21:46:14 phantom Exp $ -->
<report>
<date>
<month>January-February</month>
<year>2003</year>
</date>
<section>
<title>Introduction:</title>
<p>Another busy two months have passed in the FreeBSD project. With
5.0 released, attention is focusing on making it faster via more
fine-grained locking, adding more high-end features like large
memory (PAE) support for i386, and further progress on many other
projects. FreeBSD 5.1 is expected to ship in late May or early
June, with 5.2 following at the end of summer. A roadmap for
the push to 5-STABLE is available at <a
href="http://www.FreeBSD.org/doc/en/articles/5-roadmap">
http://www.FreeBSD.org/doc/en/articles/5-roadmap</a>. Although
the 5.x series isn't expected to fully stabilize until the 5.2
release, 5.1 promises to be an exciting release and a significant
improvement over 5.0 in terms of speed and stability.</p>
<p>Not to be forgotten, FreeBSD 4.8, the latest in the 4-STABLE
series, is nearing release. Lots of last minute work is going
into to it to deliver features like XFree86 4.3.0, Intel
HyperThreading(tm) support, and of course many more bug fixes.
Don't forget to support the FreeBSD vendors and developers by
buying a copy of the CD set when it comes out!.</p>
<p>Thanks,</p>
<p>Scott Long, Robert Watson</p>
</section>
<project>
<title>FreeBSD/MIPS Status Report</title>
<contact>
<person>
<name>
<given>Juli</given>
<common>Mallett</common>
</name>
<email>jmallett@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/mips/">FreeBSD/MIPS project
page.</url>
<url href="http://www.FreeBSD.org/platforms/mips.html">FreeBSD/MIPS
platform page.</url>
</links>
<body>
<p>Large portions of headers have been filled in, all have been stubbed
out. Minimal functions and data elements have been stubbed out or
filled in. Machinery added to support some requisite tunables for
building real kernels. GCC fixed to generate correct local label
prefixes making it possible to link real kernels. Work begun on
providing enough to create and boot real kernels, on real hardware.
Decision to only support MIPS-III and above made.</p>
</body>
</project>
<project>
<title>BSDCon 2003</title>
<contact>
<person>
<name>
<given>Gregory</given>
<common>Shapiro</common>
</name>
<email>gshapiro@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.usenix.org/events/bsdcon03/cfp/">BSDCon 2003 Call For Papers</url>
</links>
<body>
<p>The BSDCon 2003 Program Committee invites you to contribute
original and innovative papers on topics related to BSD-derived
systems and the Open Source world. Topics of interest include
but are not limited to:</p>
<ul>
<li>Embedded BSD application development and deployment</li>
<li>Real world experiences using BSD systems</li>
<li>Using BSD in a mixed OS environment</li>
<li>Comparison with non-BSD operating systems; technical, practical, licensing (GPL vs. BSD)</li>
<li>Tracking open source development on non-BSD systems</li>
<li>BSD on the desktop</li>
<li>I/O subsystem and device driver development</li>
<li>SMP and kernel threads</li>
<li>Kernel enhancements</li>
<li>Internet and networking services</li>
<li>Security</li>
<li>Performance analysis and tuning</li>
<li>System administration</li>
<li>Future of BSD</li>
</ul>
<p>Submissions in the form of extended abstracts are due by
April 1, 2003. Be sure to review the extended abstract
expectations before submitting. Selection will be based on the
quality of the written submission and whether the work is of
interest to the community.</p>
<p>We look forward to receiving your submissions!</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>
<links>
<url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url>
<url href="http://bluez.sf.net">Linux BlueZ stack</url>
<url href="http://sourceforge.net/projects/openobex/">OpenOBEX</url>
</links>
<body>
<p>I'm very pleased to announce that another release is available for
download at <a
href="http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz">
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz</a></p>
<p>This release features new in-kernel RFCOMM implementation that
provides SOCK_STREAM sockets interface. This makes old user-space
RFCOMM daemon obsolete. People should not use old user-space
RFCOMM daemon any longer. The release features new RFCOMM PPP
daemon that supports DUN and LAN profiles. Note: PPP patch
(support for chat scripts in -direct mode) is required for DUN
support. Look for it in the mailing list archive or contact me
directly. People with Bluetooth enabled cell phones can now
use them to access Internet.</p>
<p>The Bluetooth sockets layer has been cleaned up. People should not
see any WITNESS complaints with new code. Locking issues have been
revisited and code in much better shape now, although it probably
is not 100% SMP ready just yet. The code should work on SMP system
anyway because sockets layer is still under Giant.</p>
<p>The simple OBEX server and client (based on OpenOBEX library) is
complete. OBEX File Push and OBEX File Transfer profiles work and
have been tested with Sony Ericsson T68i cell phone and Bluetooth
3COM stack on Windows2K. It is now possible to send pictures,
address book and calendar entries from the cell phone via
Bluetooth. Minor bug in OpenOBEX library has been fixed and OPEX
Put-Empty command now works.</p>
<p>Due to changes in API userland tools must be in sync with the
kernel. People should install new include files, recompile and
reinstall all userland tools as part of upgrade. I'm sorry about
that.</p>
</body>
</project>
<project>
<title>FreeBSD 4.8 Release Engineering</title>
<contact>
<person>
<name>
<given>Murray</given>
<common>Stokely</common>
</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/releases/4.8R/schedule.html">FreeBSD
4.8 Release Schedule.</url>
</links>
<body>
<p>The FreeBSD 4.8 Release Process is well underway. The RELENG_4
branch has been under code freeze since February 15, and
the first release candidates were made available in early March.
A testing guide has been put together and is available from
http://www.FreeBSD.org/releases/4.8R/qa.html.</p>
<p>Developers should coordinate with re@FreeBSD.org about any
changes they would like to include in this release, and users
are encouraged to try out the release candidates and help find
as many bugs as possible now, before the final release is
made.</p>
<p>FreeBSD 4.8 represents the newest production release from the
stable '4.X' branch. It does not include all of the features
that were made available in the "new technology" 5.0
release in January.</p>
</body>
</project>
<project>
<title>New Doceng Body Formed</title>
<contact>
<person>
<name>
<given>Murray</given>
<common>Stokely</common>
</name>
<email>doceng@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/internal/doceng.html" />
</links>
<body>
<p>The doceng@ team is a new body to handle some of the
meta-project issues associated with the FreeBSD Documentation
Project. The main responsibilities of this team are to grant
approval of new doc committers, to manage the doc release
process, to ensure the documentation toolchains are functional,
to maintain the doc project primer, and to maintain the sanctity
of the doc/ and www/ trees. The current members of this team
are Nik Clayton, Ruslan Ermilov, Jun Kuriyama, Bruce A. Mah, and
Murray Stokely.</p>
</body>
</project>
<project>
<title>KGI/FreeBSD Status Report</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/ggiport.html" />
<url href="http://kgi-wip.sf.org" />
</links>
<body>
<p>The later months have been very busy on KGI. Most of the framework
has been debugged for typical usage (fb, no accel). I got
KII (the input interface) connected to syscons through atkbd. Opening
/dev/graphic works and framebuffer resource access is permitted.
Finally, the KGIM (KGI module) framework has a better building
tree for board / monitor drivers and board drivers are now loading
with resource allocation.</p>
<p>Most important on the TODO list:
5.0-RELEASE move (I currently work with a May-2002 5.0-current).
Most of debug is now done. Let's validate!</p>
<p>Note that KGI project homepage has changed since the last report.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
<url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.0.0/ja-man-doc-5.0.tbz">package ja-man-doc-5.0.tbz</url>
</links>
<body>
<p>We have released Japanese translation of 5.0-RELEASE online manual
pages on February 2nd. Most of entries which did not exist on RELENG_4
were not yet translated. I hope we can finish such entries soon.</p>
</body>
</project>
<project>
<title>Disk I/O improvements</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>We have the first disk device driver (aac) out from under Giant
now, and in certain scenarios it gives improvements up to 20%.
The device driver API was pruned to reflect that NO_GEOM
compatibility is unnecessary, this resulted in approx 1000
lines less source code, the majority of which were removed
from the device drivers. The new API for cdevsw is a lot simpler
and hopefully less likely to confuse people. The ability to
automatically allocate a device major number has been introduced
and is already used by a handful of drivers. Checks introduced
with this facility has shown that the uniqueness of manually
allocated major numbers had already broken down.<p>
</p>Work continues on the statistics collection API and on a unified
API for manual configuration of GEOM nodes.</p>
</body>
</project>
<project>
<title>Support for PAE and >4G ram on x86</title>
<contact>
<person>
<name>
<given>Jake</given>
<common>Burkholder</common>
</name>
<email>jake@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Support for PAE is mostly complete, and has been checked into the
jake_pae branch. The approach that is being taken to add support for
PAE is to allow the pmap module to view the page table directory as 4
pages instead of 1, and to avoid using the 3rd level structure, the page
directory pointer table, as much as possible. Due to its small size, 32
bytes, the PDPT cannot be uniformly recursively mapped, and as such does
not provide a regular multi level structure like the page tables used by
the alpha or x86-64 architectures. What remains to be done for PAE
support is to develop an API for manipulating page table entries which
will allow idempotent 64 bit loads and stores to be used where
necessary.</p>
<p>Experimental support for >4G ram using PAE has been developed and
checked into the jake_pae_test branch in Perforce. This involved adding
a physical address type separate from virtual addresses, for use by the
vm system and bus code which needs to use physical addresses directly.
Initial testing has shown good results with device drivers that can dma
to 64 bit physical addresses.</p>
<p>Funding for this project is being provided by DARPA and Network
Associate Laboratories, and hardware support by
<a href="http://www.freebsdsystems.com">FreeBSD Systems</a>.</p>
</body>
</project>
<project>
<title>FreeBSD Security Officer Team</title>
<contact>
<person>
<name>
<given>Jacques</given>
<common>Vidrine</common>
</name>
<email>nectar@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/security/"/>
</links>
<body>
<p>In the period from September 2002 through February 2003, the
FreeBSD Security Team email aliases saw 1297 messages, a much
smaller volume than over the summer (remember the Apache and OpenSSL
worms? 4.6.1 oops I mean 4.6.2-RELEASE?).</p>
<p>Also during this period: 95 items were added to the SO
issue-tracking database; 39 of these involved the FreeBSD base
system while the rest involved ports. 9 new Security Advisories
were published, 2 of which covered issues unique to FreeBSD.</p>
<p>In January, the SO published a new PGP key (ID 0xCA6CDFB2, found
on the FTP site and in the Handbook). This aligned the set of those
who possess the corresponding private key with the membership of the
security-officer alias published on the FreeBSD Security web site.
It also worked around an issue with the deprecated PGP key being
found corrupted on some public key servers.</p>
<p>In February, Mike Tancsa of Sentex donated two machines to
the Security Officer. These have been a great help already in
testing the security branches, preparing patches, and generating
updated binaries. Thank you very much, Mike!</p>
</body>
</project>
<project>
<title>FreeBSD GNOME Project</title>
<contact>
<person>
<name>
<given>Joe</given>
<common>Marcus</common>
</name>
<email>marcus@FreeBSD.org</email>
</person>
<person>
<name>
<given>Maxim</given>
<common>Sobolev</common>
</name>
<email>sobomax@FreeBSD.org</email>
</person>
<person>
<name>
<given>Adam</given>
<common>Weinberger</common>
</name>
<email>adamw@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
Homepage.</url>
</links>
<body>
<p>FreeBSD 4.8-RELEASE will continue in the tradition of
5.0-RELEASE, and include GNOME 2 as the default GNOME desktop.
This means that 4.8 will ship with GNOME 2.2.</p>
<p>Following on the heels of the recent GNOME 2.2 release, GNOME 2.3
snapshots are gearing up. The development schedule is
available from <a href="http://www.gnome.org/start/2.3/">
http://www.gnome.org/start/2.3/</a>. Ports will be
made available the same way they were for the 2.1 development
releases. Stay tuned to freebsd-gnome@ for more details.</p>
<p>We are currently in another ports freeze in preparation for
4.8-RELEASE. Following the freeze, a new bsd.gnome.mk will
be committed that effectively removes the USE_GNOMENG macro.
This new version will add support for GNOME 2 as well as
setup backward compatibility for ports that have not yet
been converted to the new GNOME infrastructure. People
interested in testing this new Mk file, can check out
the ``ports'' module following the instructions at
<a href="http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi">
http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi</a>.</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>Work on PowerPC is progressing steadily. The system can now boot
multi-user from the net and disk. ATA-DMA is being integrated with
the ATAng code, and support for older G3 machines is being added.</p>
</body>
</project>
<project>
<title>FreeBSD C99 &amp; POSIX Conformance Project</title>
<contact>
<person>
<name>
<given>Mike</given>
<common>Barcroft</common>
</name>
<email>mike@FreeBSD.org</email>
</person>
<person>
<name>
<common>FreeBSD-Standards Mailing List</common>
</name>
<email>standards@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/c99/" />
<url href="http://people.FreeBSD.org/~schweikh/posix-utilities.html" />
</links>
<body>
<p>January and February were quiet months that saw with them the
addition of some C99 math functions and macros, which include:
fpclassify(), isfinite(), isgreater(), isgreaterequal(), isinf(),
isless(), islessequal(), islessgreater(), isnan(), isnormal(),
and signbit(). Additional C99 math library support is in the
works.</p>
</body>
</project>
<project>
<title>Buffer Cache lockdown</title>
<contact>
<person>
<name>
<given>Jeff</given>
<common>Roberson</common>
</name>
<email>jeff@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Most of the file system buffer cache has been reviewed and protected.
The vnode interlock was extended to cover some buffer flag fields so
that a separate interlock was not required. The global buffer queue
data structures were locked and counters were converted to atomic ops.
The BUF_*LOCK functions grew an interlock argument so that buffers
could be safely removed from the vnode clean and dirty lists. The
lockmgr lock is now required for all access to buf fields. This was
not strictly followed before because splbio provided the needed
protection.</p>
<p>There are a few areas of code that need to be protected and cleaned up
before giant can be pushed down. Most notably the background write
code is currently unsafe without giant. Also, many of the VM bits that
the buffer cache relies on are not safe. This work has been done with
the expectation that the VM and VFS subsystems will be giant free
soon.</p>
</body>
</project>
<project>
<title>ULE Scheduler</title>
<contact>
<person>
<name>
<given>Jeff</given>
<common>Roberson</common>
</name>
<email>jeff@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The ULE scheduler has been committed to the 5.0-CURRENT branch. Early
adopters and experimenters are welcome to try it and submit bug
reports. It has shown noticeable performance improvements over the old
scheduler under some workloads. There are currently problems with
nice fairness but otherwise the interactive performance is very good.
More work to improve the load balancing algorithm is required as well.
This should be ready for use by the general FreeBSD user base in the
next month or so.</p>
</body>
</project>
<project>
<title>Read-ahead performance</title>
<contact>
<person>
<name>
<given>Jeff</given>
<common>Roberson</common>
</name>
<email>jeff@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Some improvements have been made to the clustered read ahead code. They
allow for many more outstanding IO requests when an application does
sequential access. This has a larger impact on RAID systems than on
single disk systems. The maximum number of file system blocks that we
will read ahead is tunable via the 'vfs.read_max' sysctl. This
optimization has shown a 20% improvement in simple tests.</p>
</body>
</project>
<project>
<title>Status Report for Newbus lockdown</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Locking of the non-obj parts of newbus is nearing completion.
A single lock is used for the device tree. Minimal changes to
subr_bus have so far been necessary to make this work, however
some lock order issues remain. After this
work, it will no longer be necessary to hold Giant to call
device_* routines safely. kobj work is being done by others and
will likely require more extensive design work to make SMP
friendly.</p>
</body>
</project>
<project>
<title>TCP congestion control</title>
<contact>
<person>
<name>
<given>Jeffrey</given>
<common>Hsu</common>
</name>
<email>hsu@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>The objective of this effort is to improve the performance, stability,
and correctness of the BSD networking stack by adding support for
new standards and standards track proposals while maintaining compliance
with existing specifications. The upcoming 4.8 and 5.1 releases will
be the first ones using the new NewReno logic. Recently, we
implemented the Limited Transmit algorithm (RFC 3042) which benefits
connections with small congestion windows, as happens, for example,
on many short web connections. We also recently added support for larger
sized starting congestion windows as described in RFC 3390. This helps
short TCP connections as well as those with large round-trip delays,
such as those over satellite links.</p>
</body>
</project>
<project>
<title>SMP locking for network stack</title>
<contact>
<person>
<name>
<given>Jeffrey</given>
<common>Hsu</common>
</name>
<email>hsu@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>The list of subsystems locked up include IP, UDP, TCP,
ifaddr reference counting, syncache, the ifnet list, routing
radix trees, and ARP. These have already been committed into the tree.
In addition, SMP locking for raw IP, divert socket processing,
and Unix domain sockets have also recently been completed and tested.
Work is currently being done in some of the subsystems required
to make parallel networking processing SMP-safe.</p>
</body>
</project>
</report>

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

@ -1,869 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-jan-2004-feb-2004.xml,v 1.5 2004/04/30 12:36:11 josef Exp $ -->
<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
<a href="http://portsmon.firepipe.net/faq.html">FAQ</a> 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-only 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
<a href="http://www.marcuscom.com/tinderbox/">package build
server</a>
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 to the
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>

2147
en/news/status/report-jan-2005-mar-2005.xml
View file

File diff suppressed because it is too large Load diff

1467
en/news/status/report-jan-2006-mar-2006.xml
View file

File diff suppressed because it is too large Load diff

1206
en/news/status/report-july-2001.xml
View file

File diff suppressed because it is too large Load diff

1061
en/news/status/report-july-2002-aug-2002.xml
View file

File diff suppressed because it is too large Load diff

2341
en/news/status/report-july-2004-dec-2004.xml
View file

File diff suppressed because it is too large Load diff

2037
en/news/status/report-july-2005-oct-2005.xml
View file

File diff suppressed because it is too large Load diff

830
en/news/status/report-june-2001.xml
View file

@ -1,830 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-june-2001.xml,v 1.7 2004/04/04 21:46:14 phantom Exp $ -->
<report>
<date>
<month>June</month>
<year>2001</year>
</date>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
$FreeBSD: www/en/news/status/report-june-2001.xml,v 1.7 2004/04/04 21:46:14 phantom Exp $
</cvs:keyword>
</cvs:keywords>
<section>
<title>Introduction</title>
<p>One of the benefits of the FreeBSD development model is a focus
on centralized design and implementation, in which the operating
system is maintained in a central repository, and discussed on
centrally maintained lists. This allows for a high level of
coordination between authors of various components of the system,
and allows policies to be enforced over the entire system, covering
issues ranging from architecture to style. However, as the FreeBSD
developer community has grown, and the rate of both mailing list
traffic and tree modifications has increased, making it difficult
even for the most dedicated developer to remain on top of all the
work going on in the tree.</p>
<p>The FreeBSD Monthly Development Status Report attempts to
address this problem by providing a vehicle that allows developers
to make the broader community aware of their on-going work on
FreeBSD, both in and out of the central source repository. This is
the first issue, and as such is an experiment. For each project and
sub-project, a one paragraph summary is included, indicating
progress since the last summary (in this case, simply recent
progress, as there have been no prior summaries).</p>
<p>This status report may be reproduced in whole or in part, as
long as the source is clearly identified and appropriate credit
given.</p>
</section>
<section>
<title>Future Editions</title>
<p>Assuming there is some positive feedback on this idea, and that
future submissions get made such that there is content for future
issues, the goal is to release a development status report once a
month. As such, the next deadline will be July 31, 2001, with a
scheduled publication date in the first week of August. This will
put the status report on a schedule in line with the calendar, as
well as providing a little over a month until the next deadline,
which will include a number of pertinent events, including the
Annual USENIX Technical Conference in Boston, MA. Submissions
should be e-mailed to:</p>
<blockquote>
<a href="mailto:robert+freebsd.monthly@cyrus.watson.org">
robert+freebsd.monthly@cyrus.watson.org</a>
</blockquote>
<p>Many submitters will want to wait until the last week of July so
as to provide the most up-to-date status report; however,
submissions will be accepted at any time prior to that date.</p>
<p>
<i>-- Robert Watson &lt;
<a href="mailto:rwatson@FreeBSD.org">rwatson@FreeBSD.org</a>
&gt;</i>
</p>
</section>
<project>
<title>Binary Updater Project</title>
<contact>
<person>
<name>
<given>Eric</given>
<common>Melville</common>
</name>
<email>eric@FreeBSD.org</email>
</person>
<person>
<name>
<given>Murray</given>
<common>Stokely</common>
</name>
<email>murray@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~murray/updater.html" />
</links>
<body>
<p>The FreeBSD Binary Updater Project aims to provide a secure
mechanism for the distribution of binary updates for FreeBSD.
This project is complementary to the Open Packages and libh
efforts and there should be very little overlap with those
projects. The system uses a client / server mechanism that allows
clients to install any known "profile" or release of FreeBSD over
the network. Where a specific profile might contain a specific
set of FreeBSD software to install, additional packages, and
configuration actions that make it more ideal for a specific
environment (ie FreeBSD 4.3 Secure Web Server Profile)</p>
<p>The system can currently be used to install a FreeBSD system
or perform the most simple of upgrades but many features are
absent. In particular, the client is in its infancy and much work
remains to be done. We need additional developers so please get
in touch with us at
<a href="mailto:updater@osd.bsdi.com">updater@osd.bsdi.com</a>
if you are interested in spending some cycles on this.</p>
</body>
</project>
<project>
<title>Problem Reports</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://phk.freebsd.dk/Gnats/" />
</links>
<body>
<p>Poul-Henning Kamp kicked off a drive to get our GNATS PR
database cleaned up so the wheat can be sorted from the chaff.
Progress is good, but there is still a lot of work to do. Give a
hand if you can. Remember: every unhandled PR is a pissed off
contributor or user.</p>
</body>
</project>
<project>
<title>CVSROOT script rewrite/tidy</title>
<contact>
<person>
<name>
<given>Josef</given>
<common>Karthauser</common>
</name>
<email>joe@FreeBSD.org</email>
</person>
</contact>
<body>
<p>I'm in the process of rewriting the CVSROOT/scripts to make
them more clean and configurable. A lot of other projects also
use these and so it makes sense to make them as easy to use in
other environments as possible.</p>
<p>Status: work in progress. There is now a configuration file,
but not all the scripts use it yet.</p>
</body>
</project>
<project>
<title>DEVFS</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work is progressing on implementing true cloning devices in
DEVFS. Brian Somers and Poul-Henning Kamp are working to make
if_tun the first truly cloning driver in the system. Next will be
the pty driver and the bpf driver.</p>
<p>From July 1st DEVFS will be standard in -current.</p>
</body>
</project>
<project>
<title>digi driver</title>
<contact>
<person>
<name>
<given>Brian</given>
<common>Somers</common>
</name>
<email>brian@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Added the digi driver. Initial work was done by John Prince
&lt;johnp@knight-trosoft.com&gt;, but all the modular stuff was
done by me and initial work on supporting Xe and Xi cards (ala
dgb) was done by me. I'm now awaiting an Xe card being sent from
joerg@ (almost a donation) so that I can get that side of things
working properly.</p>
</body>
</project>
<project>
<title>Diskcheckd</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://phantom.cris.net/freebsd/projects/viewproj.php?p_id=15" />
</links>
<body>
<p>Ben Smithurst has written a "diskcheckd" daemon which will
read all sectors on the disks over a configured period. With
recent increases in disksizes it is by no means a given that disk
read errors will be discovered before they are fatal. This daemon
will hopefully result in the drive firmware being able to
relocate bad sectors before they become unreadable. This code is
now committed to 5.0-CURRENT.</p>
</body>
</project>
<project>
<title>if_fxp driver</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>In the last month (May-June), the new fxp driver was brought
into -stable. This new driver uses the common MII code, so
support for new PHYs is easy to add. Support for the new Intel
82562 chips was added. The driver was updated to add VLAN support
and a workaround for a bug affecting Intel 815-based boards.</p>
</body>
</project>
<project>
<title>Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@eyesbeyond.com</email>
</person>
</contact>
<body>
<p>The FreeBSD Java Project has continued its "behind the scenes"
work over the last month. Progress was made both technically,
with the help of Bill Huey (of Wind River), on a port of JDK
1.3.1 and legally, with Nate Williams continuing negotiations
with Sun on a mutually acceptable license to release a binary
Java 2 SDK under. The JDK 1.2.2 port has also seen some
development, with a new patchset likely to be released soon which
includes JPDA and NetBSD support (the latter courtesy of Scott
Bartram).</p>
</body>
</project>
<project>
<title>Kernel Graphics Interface port</title>
<contact>
<person>
<name>
<given>Nicolas</given>
<common>Souchu</common>
</name>
<email>nsouch@fr.alcove.com</email>
</person>
</contact>
<links>
<url href="http://kgi.sourceforge.net/" />
</links>
<body>
<p>The Kernel Graphics Interface project has worked for several
years to provide a framework for graphic drivers under Linux
receiving input from other groups like the UDI project. Currently
the KGI core implementation is quite settled, as is the driver
coding model as a whole. Work is being done to newbussify KGI and
produce a kld, as part of a future redesign of the graphics
subsystem in FreeBSD. KGI will be an alternative for graphic card
producers that don't accept the XFree86 model of userland graphic
adapters and will also provide accelerated support for any other
graphic alternative.</p>
</body>
</project>
<project>
<title>libh Project</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Langer</common>
</name>
<email>alex@FreeBSD.org</email>
</person>
<person>
<name>
<given>Nathan</given>
<common>Ahlstrom</common>
</name>
<email>nra@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~alex/libh/" />
</links>
<body>
<p>The libh project is a next generation sysinstall. It is
written in C++ using QT for its graphical frontend and tvision
for its console support. The menus are scriptable via an embedded
tcl interpreter. It has been growing functionality quite a bit
lately, including a new disklabel editor. Current work is on
installation scripts for CDROM, FTP, ... installs as well as a
fully functional standalone disk-partition and label editor. The
GUI API was extended a little and many bugs were fixed. There
seems to be some interest in i18n work.</p>
</body>
</project>
<project>
<title>Mount(2) API</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Maxime Henrion is working on implementing a new and more
extensible mount(2) systemcall, mainly to overcome the 32 bits
for mountoptions limit, secondary goal to make it possible to
mount filesystems from inside the kernel.</p>
</body>
</project>
<project>
<title>OLDCARD pccard implementation</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>In the last two months, the OLDCARD pccard implementation was
rototilled to within an inch of its life. Many new pci cardbus
bridges were added. Power handling was improved. PCI Card cardbus
bridges are nearly supported and should be committed in early
June to the tree. This will likely be the last major work done on
OLDCARD. After pci cards are supported, work will shift to
improving NEWCARD.</p>
</body>
</project>
<project>
<title>PowerPC Port</title>
<contact>
<person>
<name>
<given>Benno</given>
<common>Rice</common>
</name>
<email>benno@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The PowerPC port is proceeding well. All seems to be working
in pmap.c after a number of problems encountered where FreeBSD
passes a vm_page_t to a NetBSD-derived function that expects a
vm_offset_t. Then after debugging the atomic operations code, I'm
now at the point where VM appears to be initialized and it's now
hanging while in sys/kern/kern_malloc.c:kmeminit(). Progress
continues. =)</p>
</body>
</project>
<project>
<title>PPP</title>
<contact>
<person>
<name>
<given>Brian</given>
<common>Somers</common>
</name>
<email>brian@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Developing full MPPE support for Andre Opperman @ Monzoon in
Switzerland. Work is now complete and will eventually be brought
into -current, but no dates are yet known.</p>
</body>
</project>
<project>
<title>pseudofs</title>
<contact>
<person>
<name>
<given>Dag-Erling</given>
<common>Smorgrav</common>
</name>
<email>des@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Pseudofs is a framework for pseudo-filesystems, like procfs
and linprocfs. The goal of pseudofs is twofold:</p>
<ul>
<li>eliminate code duplication between (and within) procfs and
linprocfs</li>
<li>isolate procfs and linprocfs from the complexities of the
vfs system to simplify maintenance and further
development.</li>
</ul>
<p>Pseudofs has reached the point where it is sufficiently
functional and stable that linprocfs has been almost fully
reimplemented on top of it; the only bit that's missing is the
proc/&lt;pid&gt;/mem file.</p>
<p>The primary to-do item for pseudofs right now is to add
support for writeable files (which are required for procfs, and
are quite a bit less trivial to handle than read-only files). In
addition, pseudofs needs either generic support for raw
(non-sbuf'ed, possibly mmap'able) files, or failing that,
special-case code to handle proc/&lt;pid&gt;/mem.</p>
</body>
</project>
<project>
<title>RELNOTESng</title>
<contact>
<person>
<name>
<given>Bruce</given>
<common>A. Mah</common>
</name>
<email>bmah@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~bmah/relnotes/" />
</links>
<body>
<p>RELNOTESng is the name I've given to the rewrite of the *.TXT
files that typically accompany a FreeBSD release. The information
from these files (which include, among other things, the release
notes and the supported hardware list) have been reorganized and
converted to SGML. This helps us produce the documentation in
various formats, as well as facilitating the maintenance of
documentation for multiple architectures. This work was recently
committed to -CURRENT, and I intend to MFC it to 4-STABLE before
4.4-RELEASE.</p>
</body>
</project>
<project>
<title>SMPng Project</title>
<contact>
<person>
<name>
<given>John</given>
<common>Baldwin</common>
</name>
<email>jhb@FreeBSD.org</email>
</person>
<person>
<name>
<given>Jake</given>
<common>Burkholder</common>
</name>
<email>jake@FreeBSD.org</email>
</person>
<person>
<name>
<given>SMP</given>
<common>Mailing list</common>
</name>
<email>smp@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~jasone/smp/" />
</links>
<body>
<p>The SMPng project aims to provide multithreaded support for
the FreeBSD kernel. Currently the kernel still runs almost
exclusively under the Giant kernel lock. Recently, progress has
been made in locking the process group and session structures as
well as file descriptors by Seigo Tanimura-san. Alfred Perlstein
has also added in a giant lock around the entire virtual memory
(VM) subsystem which will eventually be split up into several
smaller locks. The locking of the VM subsystem has proved tricky,
and some of the current effort is focused on finding and fixing a
few remaining bugs in on the alpha architecture.</p>
</body>
</project>
<project>
<title>SMPng mbuf allocator</title>
<contact>
<person>
<name>
<given>Bosko</given>
<common>Milekic</common>
</name>
<email>bmilekic@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~bmilekic/code/mb_slab/" />
</links>
<body>
<p>mb_alloc is a new specialized allocator for mbufs and mbuf
clusters. Presently, it offers various important advantages over
the old (status quo) mbuf allocator, particularly for MP
machines. Additionally, it is designed with the possibility of
future enhancements in mind.</p>
<p>Presently in initial review &amp; testing stages, most of the
code is already written.</p>
</body>
</project>
<project>
<title>Sparc64 Port</title>
<contact>
<person>
<name>
<given>Jake</given>
<common>Burkholder</common>
</name>
<email>jake@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work has (re)started on a port of FreeBSD to the UltraSPARC
architecture, specifically targeting PCI based workstations. Jake
Burkholder will be porting the kernel, and Ade Lovett has
expressed an interest in working on userland. Recent work on the
project includes:</p>
<ul>
<li>built a gnu cross toolchain targeting sparc64</li>
<li>obtained remote access to an ultra 5 development machine
(thanks to emmy)</li>
<li>developed a minimal set of headers and source files to
allow the kernel to be compiled and linked</li>
<li>implemented a mini-loader which relocates the kernel, maps
it into the tlbs and calls it</li>
<li>nabbed Benno Rice's openfirmware console driver which
allows printf and panic to work</li>
</ul>
<p>At this point the kernel can be net-booted and prints the
FreeBSD copyright before calling code that is not yet
implemented. I am currently working on a design for the pmap
module and plan to begin implementation in the next few days.</p>
</body>
</project>
<project>
<title>TrustedBSD</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/" />
</links>
<body>
<p>The TrustedBSD Project seeks to improve the security of the
FreeBSD operating system by adding new security features, many
derived from common trusted operating system requirements. This
includes Access Control Lists (ACLs), Fine-grained Event Logging
(Audit), Fine-grained Privileges (Capabilities), Mandatory Access
Control (MAC), and other architecture features, including file
system extended attributes, and improved object labeling.</p>
<p>Individual feature status reports are documented separately
below; in general, basic features (such as EAs, ACLs, and kernel
support for Capabilities) will be initially available in
5.0-RELEASE, conditional on specific kernel options. A
performance-enhanced version of EAs is currently being targeted
at 6.0-RELEASE, along with an integrated capability-aware
userland, and MAC support.</p>
</body>
</project>
<project>
<title>TrustedBSD: ACLs</title>
<contact>
<person>
<name>
<given>Chris</given>
<common>D. Faulhaber</common>
</name>
<email>jedgar@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Patches are now available to add ACL support to cp(1) and
mv(1) along with preliminary support for install(1). Ilmar's i18n
patches for getfacl(1) and setfacl(1) need to be updated for the
last set of changes and committed. Some other functional
improvements are also in the pipeline.</p>
</body>
</project>
<project>
<title>TrustedBSD Capabilities</title>
<contact>
<person>
<name>
<given>Thomas</given>
<common>Moestl</common>
</name>
<email>tmm@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The kernel part of the capability implementation is mostly
finished; all uses of suser() and suser_xxx() and nearly all
comparisons of uid's with 0 have been converted to use the newly
introduced cap_check() call. Some details still need
clarification. More documentation for this needs to be done.</p>
<p>POSIX.2c-compatible getfcap and setfcap programs have been
written. Experimental capability support in su(1), login(1),
install(1) and bsd.prog.mk is being tested.</p>
<p>Support for capabilities, ACL's, capabilities and MAC labels
in tar(1) is being developed; only the capability part is tested
right now. Generic support for extended attributes is planned,
this will require extensions to the current EA interface, which
are written and will probably be committed to -CURRENT in a few
weeks. A port of these features to pax(1) is planned.</p>
</body>
</project>
<project>
<title>TrustedBSD MAC and Object Labeling</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/" />
</links>
<body>
<p>An initial prototype of a Mandatory Access Control
implementation was completed earlier this year, supporting
Multi-Level Security, Biba Integrity protection, and a more
general jail-based access control model. Based on that
implementation, I'm now in the process of improving the FreeBSD
security abstractions to simplify both the implementation and
integration of MAC support, as well as increase the number of
kernel objects protected by both discretionary and mandatory
protection schemes. Generic object labeling introduces a
structure not dissimilar in properties to the kernel ucred
structure, only it is intended to be associated with kernel
objects, rather than kernel subjects, permitting the creation of
generic security protection routines for objects. This would
allow the easy extension of procfs and devfs to support ACLs and
MAC, for example. A prototype is underway, with compiling and
running code and simple protections now associated with
sysctl's.</p>
</body>
</project>
</report>

2625
en/news/status/report-june-2006-oct-2006.xml
View file

File diff suppressed because it is too large Load diff

974
en/news/status/report-mar-2003-sep-2003.xml
View file

@ -1,974 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-mar-2003-sep-2003.xml,v 1.3 2004/04/07 11:27:47 phantom Exp $ -->
<report>
<date>
<month>March-September</month>
<year>2003</year>
</date>
<section>
<title>Introduction:</title>
<p>The FreeBSD Bi-monthly status reports are back! In this edition, we
catch up on seven highly productive months and look forward to
the end of 2003.</p>
<p>As always, the FreeBSD development crew has been hard at work. Support
for the AMD64 platform quickly sprang up and is nearly complete. KSE
has improved greatly since the 5.1 release and will soon become the
default threading package in FreeBSD. Many other projects are in the
works to improve performance, enhance the user experience, and expand
FreeBSD into new areas. Take a look below at the impressive summary of
work!</p>
<p>Scott Long, Robert Watson</p>
</section>
<project>
<title>VideoBSD</title>
<contact>
<person>
<name>
<given>John-Mark</given>
<common>Gurney</common>
</name>
<email>jmg@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~jmg/videobsd.html">Documentation of
VideoBSD</url>
</links>
<body>
<p>Still in the planning stage. Working on creating an extensible
interface that is usable for both userland and kernel implementations
for device drivers. Deciding on how to interface userland implemented
device drivers with applications.</p>
</body>
</project>
<project>
<title>KSE</title>
<contact>
<person>
<name>
<given>Dan</given>
<common>Eischen</common>
</name>
<email>deischen@FreeBSD.org</email>
</person>
<person>
<name>
<given>David</given>
<common>Xu</common>
</name>
<email>davidxu@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/kse/index.html">KSE Project
Page</url>
</links>
<body>
<p>KSE seems to be working well on x86, amd64, and ia64. The
alpha userland bits are done, but a couple of functions are
unimplemented in the kernel. For sparc64, the necessary
functions are implemented in the kernel, but the userland
context switching functions need more attention.</p>
<p>Since 5.1, efficient scope system threads (no upcalls when they block)
have been implemented, and KSE based pthread library can have both POSIX
scope process threads and scope system threads. It is also possible
that KSE based pthread library can implement pthread both in 1:1 and M:N
mode, I know Dan has such Makefile file patch for libkse not yet
committed.</p>
<p>KSE program now can work under ULE scheduler, its efficient should be
improved under the new scheduler in future. BSD scheduler is still the
best scheduler for current KSE implement.</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">Project home
page.</url>
</links>
<body>
<p>Much has happened since the last bi-monthly report, which was more
than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released
for example. With FreeBSD 5.2 approaching quickly, we're not going
to look back too far when it comes to our achievements. There's too
much ahead of us...</p>
<p>Two milestones have been reached after FreeBSD 5.1. The first is the
ability to support both Intel and HP machines with sources in CVS.
This due to a whole new driver for serial ports, or UARTs. Unfortunately
this still implies that syscons is not configured. That's another task
for another time, but keep an eye on KGI/FreeBSD...
The second milestone is the completion of KSE support. Both M:N and
1:1 threading is functional on ia64 and the old libc_r library has been
obsoleted. Testing has shown that KSE (i.e. M:N) may well become the
default threading model. It's looking good.</p>
<p>The ABI hasn't changed after 5.1 and the expectation is that it won't
change much. This means that we can think about becoming a tier 1
platform. This also means we need gdb(1) support. Work on it has been
started but the road is bumpy and long.
Kernel stability also has improved significantly and we typically have
one kernel panic remaining: VM fault on no fault entry. This will be
addressed with the long awaited PMAP overhaul (see below).</p>
<p>Most work for FreeBSD 5.2 will be "sharpening the saw". Get those
loose ends tied. This is a slight change of plan made possible by a
slip in the release schedule. The 5.2 release is not going to be the
start of the -stable branch; it has been moved to 5.3. So, we use the
extra time to prepare the ground for 5.3.</p>
<p>The planned PMAP overhaul will probably be finished after 5.2. This
should address all known issues with SMP and fix those last panics.
As a side-effect, major performance improvements can be expected. More
news about this in the next status reports.</p>
</body>
</project>
<project>
<title>Disk I/O</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The following items are in progress in the Disk I/O area:
Turn scsi_cd.c into a GEOM driver. (Patch out for review).
Turn atapi-cd.c into a GEOM driver.
Turn fd.c into a GEOM driver.
Move softupdates and snapshot processing from SPECFS to UFS/FFS.
Move userland access to device drivers out of vnodes.</p>
<p>Once these preliminaries are dealt with, scatter/gather and
mapped/unmapped support will be added to struct bio/GEOM.</p>
</body>
</project>
<project>
<title>Binary security updates for FreeBSD</title>
<contact>
<person>
<name>
<given>Colin</given>
<common>Percival</common>
</name>
<email>cperciva@daemonology.net</email>
</person>
</contact>
<links>
<url href="http://www.daemonology.net/freebsd-update/" />
</links>
<body>
<p>FreeBSD Update is a system for tracking the FreeBSD release
(security) branches. In addition to being faster and more
convenient than source updates, FreeBSD Update also requires
less bandwidth and is more secure than source updates via
CVSup. However, FreeBSD Update is limited; it can only
update files which were installed from an official RELEASE
image and not recompiled locally. Right now I'm publishing
binary updates for 4.7-RELEASE and 4.8-RELEASE; since my
only available box takes 3.5 hours to buildworld, I don't
have enough resources to do any more than that.</p>
<p>In the near future, I'd like to: Find someone who is
willing to donate a faster buildbox; start building updates
for other releases (at a minimum, for all "supported" FreeBSD
releases); add warnings if a file would have been updated
but can't be updated because it was recompiled locally; add
code to compare the local system against a list of "valid"
MD5 hashes for intrusion detection purposes; and add support
for cross-signing, whereby several machines could build
updates independently to protect against buildbox
compromise.</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">
http://pf4freebsd.love2party.net</url>
<url href="http://www.benzedrine.cx/pf.html">PF homepage</url>
<url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url>
</links>
<body>
<p>The project started this spring and released version 1.0 with a port
installation (security/pf) in may 2003. Version 2.0 is on the doorstep
as OpenBSD 3.4 will be released. Due to the porting efforts we were
able to reveal some bugs in the OpenBSD code and provided locking for
the PFIL_HOOKS, which we utilize. Tarball installation of a loadable
kernel module for testing can be found on the project homepage, a
patchset is in the making.</p>
<p>PF was started at OpenBSD as a substitute for ipfilter and provides
the same function set. However, in the two years it exists now, it has
gained many superior features that no other packet filter has. For a
impression take a look at the pf FAQ.</p>
<p>We hope to be eventually integrated into the base system. Before that
we have to resolve some issues with tcpdump and kame.</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>
<links>
<url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url>
<url href="http://bluez.sf.net">Linux BlueZ stack</url>
<url href="http://sourceforge.net/projects/openobex/">OpenOBEX</url>
</links>
<body>
<p>I'm very pleased to announce that another release is available for
download at
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz.
I have also prepared patch for the FreeBSD source tree. The patch
was submitted for review to the committers.</p>
<p>Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4)
modules were changed to fix issue with Netgraph timeouts. The
ng_ubt(4) module was changed to fix compilation issue on -current.</p>
<p>Improved user-space utilities. Implemented new libsdp(3). Added
new sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and
obexapp(1) were changed and now can obtain RFCOMM channel via SDP
from the server. The hccontorol(8) utility now has four new
commands. The hcsecd(8) daemon now saves link keys on the disk.</p>
<p>I've been recently contacted by few individuals who whould like to
port current FreeBSD Bluetooth code to other BSD systems (OpenBSD
and NetBSD). The work is slowly progressing towards
un-Netgraph'ing current code. In the mean time Netgraph version
will be the primary supported version of the code.</p>
</body>
</project>
<project>
<title>Rescue build infrastructure</title>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordon@FreeBSD.org</email>
</person>
<person>
<name>
<given>Tim</given>
<common>Kientzle</common>
</name>
<email>kientzle@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The rescue build infrastructure has been committed. There is one
known issue with make using both the '-s' and '-j' flags that appears
to be a bug in make. Anyone interested in tracking down should contact
us.</p>
</body>
</project>
<project>
<title>Dynamically Linked Root Support</title>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Support for a dynamically linked /bin and /sbin has been committed,
although it is not turned on by default. Adventurous users can try it
out by building /bin and /sbin using the WITH_DYNAMICROOT make flag.
More testing is needed to determine if this is going to be default for
5.2-RELEASE. If anyone would like to benchmark worldstones with and
without dynamically linked /bin and /sbin, please feel free to do so
and submit the results.</p>
</body>
</project>
<project>
<title>ACPI Status Report</title>
<contact>
<person>
<name>
<given>Nate</given>
<common>Lawson</common>
</name>
<email>njl@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.root.org/~nate/freebsd/" />
</links>
<body>
<p>Work is continuing on updating ACPI with new features as well
as bugfixing. A new embedded controller driver was written in
July with support for the ACPI 2.0 ECDT as well as more robust
polling support. Also, a buffer overflow in the ACPICA resource list
handling that caused panics for some users was fixed. Marcel
helped get acpidump(8) tested and basically working on ia64.</p>
<p>Upcoming work includes integrating ACPI notifies with devd(8),
committing user-submitted drivers for ASUS and Toshiba hotkeys,
Cx processor sleep states (so my laptop doesn't burn my lap), and
power resource support for intelligently powering down unused or idle
devices.</p>
<p>Users who have problems with ACPI are encouraged to submit a PR
and email its number to acpi-jp@jp.FreeBSD.org. Bug reports
of panics or crashes have first priority and non-working features
or missing devices (except suspend/resume problems) second.
Reports of failed suspend/resume should NOT be submitted as PRs
at this time due to most of them being a result of incomplete
device support that is being addressed. However, feel free
to mail them to the list as any information is helpful.</p>
</body>
</project>
<project>
<title>uart(4)</title>
<contact>
<person>
<name>
<given>Marcel</given>
<common>Moolenaar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The uart(4) project was born out of the need to have a working
serial interface (i.e. an RS-232-C interface) in a legacy-free
configuration and after an unsuccessful attempt to convert sio(4).
The biggest problem with sio(4) is that it has been intertwined
in many ugly ways into the kernel's core. Conversion could not
happen without breaking something that invariably affects some
group of people negatively. With sio(4) as a good bad example
and a strong desire to solve multiple problems at once, the
idea of an UART (Universal Asynchronuous Receiver/Transmitter)
device that, given its generic name, could handle different
flavors of UART hardware started to settle firmly in the authors
mind.</p>
<p>The biggest challenge was of course solving the problem of the
low-level console access prior to the initialization of the bus
infrastructure and still have a driver that uses the bus access
exclusively. Along the way the problem of having an UART function
as the keyboard on sparc64 was solved with the introduction of
system devices, which also encapsulated the console as a system
device.</p>
<p>The uart(4) driver can be enhanced to support the various UART
hardware on pc98 and this is currently being worked on. Keyboard
support on sparc64 is underway as well. Plans exist for a rewrite
of the remote gdb support that uses a generic interface to allow
various drivers, including uart(4), to register itself as a
communications channel. And since uart(4) does not support multi-
port cards by itself, we likely need to either enhance puc(4) or
otherwise introduce other umbrella drivers</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>Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now
with icc 7.1 (and some patches) it is possible. There are still some bugs,
e.g. NFS doesn't work with an icc compiled kernel, IP seems to be fragile,
and some advanced optimizations trigger an ICE (Intel is working on it).
At the moment I'm waiting for our admins to install icc on the FreeBSD
cluster (we got a commercial license from Intel, so we are allowed to
distribute binaries which are compiled with icc), after that I will try
to convince some people with more knowledge of the IP and NFS parts of
the kernel to debug the remaining problems. When the icc compiled kernel
seems to work mostly bugfree the userland will get the porting focus.
Interested people may try to do a build of the ports tree with icc
independently from the status of the porting of the userland... if this
happens at the FreeBSD cluster, we would also be allowed to distribute
the binaries.</p>
<p>Benefits include: another set of compiler errors (debugging help),
more portable source, and code which is better optimized for a P4 (gcc
has some drawbacks in this area)</p>
</body>
</project>
<project>
<title>KDE FreeBSD Project</title>
<contact>
<person>
<name>
<given>KDE-FreeBSD</given>
<common>Mailinglist</common>
</name>
<email>kde@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://freebsd.kde.org/" />
</links>
<body>
<p>The FreeBSD ports were updated to KDE 3.1.4, another bug- and
security-fixes release. With this update, the QT port was updated
to version 3.2. Both will be included in FreeBSD 4.9.
Significant work was spent to fix KDE on FreeBSD-CURRENT after the
removal of the gcc -pthread Option. Automatic package builds from
KDE CVS continued to ensure and improve the quality of the upcoming
KDE 3.2 release.</p>
<p>Future: Work is in progress to setup a new server for hosting the
KDE-FreeBSD Website, Repository and another KDE CVS mirror. With
help from Marcel Moolenaar the project will try to make KDE compile
and working on the Intel IA64. And last but not least efforts are
being made to fix the currently broken kdesu program.</p>
</body>
</project>
<project>
<title>WifiBSD Status Report</title>
<contact>
<person>
<name>
<given>Jon</given>
<common>Disnard</common>
</name>
<email>masta@wifibsd.org</email>
</person>
</contact>
<links>
<url href="http://www.wifibsd.org">www.wifibsd.org</url>
</links>
<body>
<p>WifiBSD is a miniture version of FreeBSD for wireless applications.
Originally for the Soekris Net45xx line of main-boards, but is now
capable of being targeted to any hardware/architecture FreeBSD itself
supports. Although not feature complete, WifiBSD is expected to be
ready for 5.2-RELEASE. The design goal is to meet, or exceed, the
functionality of commercial/consumer 802.11 wireless gear. Features
that need attention (to name just a few) are: http interface, consol
menu interface, and installation. Volunters are welcome.</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>Work has restarted after a hiatus. Current focus is on getting
loadable modules working, NEWBUSing the NetBSD dbdma code, and
completing the BMAC ethernet driver.</p>
<p>There is a huge amount of work to do. Volunteers more than welcome!</p>
</body>
</project>
<project>
<title>AMD64 Porting</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Wemm</common>
</name>
<email>peter@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The last known bug that prevented AMD64 machines completing a
full release has been fixed - one single character error that
caused ghostscript to crash during rendering diagrams. SMP work
is nearing completion and should be committed within the next few
days. The SMP code uses the ACPI MADT table based on John Baldwin's
work-in-progress there for i386. We need to spend some time on
low level optimization because there are several suboptimal places
that have been ignored for simplicity, context switching in
particular. MTRR support has been committed and XFree86 can use
it. cvsup now works but the ezm3 port has not been updated yet.
The default data segment size limit is 8GB instead of 512M, and
the (primitive) i386 binary emulation support knows how to lower
the rlimits for executing 32 bit binaries.</p>
<p>Notable things missing still: Hardware debug register support
needs to be written; gdb is still being done as an external
set of patches relative to the not-yet-released FSF gdb tree;
DDB does not disassemble properly; DDB cannot do stack traces
without -fno-omit-frame-pointer - a stack unwinder is needed;
i386 and amd64 linux binary emulation is needed, and the i386
FreeBSD binary emulation still needs work - removing the
stackgap code in particular.</p>
<p>The platform in general is very reliable although a couple of
problems have been reported over the last week. One appears to
be a stuck interrupt, but all that code has been redone for SMP
support.</p>
</body>
</project>
<project>
<title>bsd.java.mk version 2.0</title>
<contact>
<person>
<name>
<given>Ernst</given>
<common>De Haan</common>
</name>
<email>znerd@FreeBSD.org</email>
</person>
<person>
<name>
<given>Herve</given>
<common>Quiroz</common>
</name>
<email>herve.quiroz@esil.univ-mrs.fr</email>
</person>
</contact>
<links>
<url href="http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html">Project homepage</url>
</links>
<body>
<p>The FreeBSD Java community has started an effort to improve the
current framework for Java-based ports. The main objective is the
automation of JDK/JRE build and run dependency checking.</p>
<p>The original version was aimed to ease the life of porters. Although
it has proved to be useful and reliable to a great extend, we are
currently working on a new version. We intend to reach a high degree
of flexibility to cope with the recent increase of available JDK/JRE
flavors. Furthermore, the new version will be easier to maintain,
which means improved reliability, and hopefully more frequent
updates.</p>
</body>
</project>
<project>
<title>FreeBSD Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/java/">FreeBSD Java Project</url>
</links>
<body>
<p>The BSD Java Porting Team has recently reached an exciting milestone
with the release of the first "Diablo" JDK and JRE courtesy of the
FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte
1.3.1 was the first binary release of a native FreeBSD JDK since
1.1.8 and marks an important step forward in FreeBSD Java support.</p>
<p>The team is continuing development work, with a focus on achieving
a compliant JDK 1.4 release in the near future.</p>
</body>
</project>
<project>
<title>ATAPI/CAM Status Report</title>
<contact>
<person>
<name>
<given>Thomas</given>
<common>Quinot</common>
</name>
<email>thomas@FreeBSD.org</email>
</person>
</contact>
<body>
<p>With the introduction of ATAng, some users of ATAPI/CAM have
experienced various problems. These have been mostly tracked down
to issues in the new ATA code, as well as two long-standing problems
in portions of the CAM layer that are rarely exercised with
"real" SCSI SIMs. This has also been an occasion to cleanup
ATAPI/CAM to make it more robust, and to enable DMA for devices
accessed through it, resulting in improved performances.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
<url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-man-doc-5.1.tbz">package ja-man-doc-5.1.tbz</url>
</links>
<body>
<p>We have released Japanese translation of 5.1-RELEASE online manual
pages on June 10.</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://lonesome.dyndns.org:4802/bento/errorlogs/index.html">
FreeBSD ports monitoring system</url>
</links>
<body>
<p>Several months ago, I took it upon myself to to try present the
information contained on <a href="http://bento.FreeBSD.org">the bento
build cluster</a> to be presented in a more user-friendly fashion; that
is, to be browsed by error type, by maintainer, and so forth. An early
addition was code to attempt to classify ports PRs by either "existing
port" (after assiging the most likely category and portname); "new port";
"framework" (e.g. bsd.port.mk changes); and "unknown". Various columns
about the ports PRs were added to the reports.</p>
<p>The initial intent of this was to make life easier for ports
maintainers; however, the "general" reports are also useful to anyone who
just wants to, e.g., find out if a particular port is working on their
particular architecture and OS combination before downloading it. Those
with that general interest should start with the
<a href="http://lonesome.dyndns.org:4802/bento/errorlogs/portoverview.py">
overview of one port</a>.</p>
</body>
</project>
<project>
<title>kgi4BSD Status Report</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>A lot of work done since last report: site reworked completly (see new
URL), console design with console message in text or graphic modes
implemented, implementation of a compatibility layer to compile Linux
fbdev drivers with more or less changes in the original driver
(experimental).</p>
<p>Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is
now working with the same driver as the console. A basic terminal has
now to be implemented.</p>
<p> Volonteers are welcome to the project...</p>
</body>
</project>
<project>
<title>Device_t locking</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A number of races have been identified in locking device_t.
Most of the races have been identified in making device_t have to
do with how drivers are written. Efforts are underway to identify
all the races, and to contact the authors of subsystems that can
help the drivers. Of special concern is the need for the driver
to ensure that all threads are completely out of the driver code
before detach() finishes. Of additional concern is making sure
that all sleepers are woken up before certain routines are called
so that other subsystems can ensure the last condition and leave
no dangling references. Locking device_t is relatively straight
forward apart from these issues. Towards the end of proper
locking, sample strawmen drivers are being used to work out what,
exactly proper is. Once these issues are all known and documented
in the code, efforts will be made to update relevant documentation
in the tree. There are many problems with driver locking that has
been done to date, but until we nail down how to write a driver in
current, it will be premature to contact specific driver writers
with specific concerns.</p>
</body>
</project>
<project>
<title>Cryptographic Support</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Support for several new crypto devices was added. The SafeNet 1141 is a
medium performance part that is not yet available on retail products. The
Hifn 7955 and 7956 parts are starting to appear on retail products that
should be available by the end of the year. Both devices support AES
encryption. Support for public key operations for the SafeNet devices was
recently done for OpenBSD and will be backported. Public key support for
the Hifn parts is planned.</p>
<p>A paper about the performance work done on the cryptographic subsystem
was presented at the Usenix BSDCon 2003 conference and received the best
paper award.</p>
<p>NetBSD recently imported the cryptographic subsystem.</p>
</body>
</project>
<project>
<title>Release Engineering Status</title>
<contact>
<person>
<name>
<given>Scott</given>
<common>Long</common>
</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The release of 4.9 is just around the corner and offers Physical Address
Extensions (PAE) for x86 along with the same world-class stability and
performance that is expected from the 4-STABLE series. As always, don't
forget to purchase a copy of the CD set from your favorite FreeBSD
vendor.</p>
<p>FreeBSD 5.1 was released in June and offered vastly improved
stability over 5.0 along with a working implementation of Kernel
Scheduled Entities, allowing for true multithreading of applications
across multiple CPUs. FreeBSD 5.2 will be released by the end of 2003
and will focus on improved network and overall performance.</p>
</body>
</project>
<project>
<title>Wireless Networking Support</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Numerous bugs have been fixed since the last status report (and of
course a few new ones added). Progress on improved security has been
slowed by other work. But new features and fixes are coming in from
other groups that are now sharing the code. In particular NetBSD
recently imported the revised 802.11 layer and the Linux-based MADWIFI
project is using it too (albeit in an older form). The MADWIFI users
have already contributed features such as fragmentation reassembly of
802.11 frames and improved signal monitoring. Power save polling and
an improved rate control algorothm are expected to come in from the
NetBSD folks. WPA support is still in the plans; the best estimate is
that work on that will start in January.</p>
</body>
</project>
<project>
<title>Network Subsystem Locking and Performance</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The purpose of this project is to improve performance of the network
subsystem. A major part of this work is to complete the locking of the
networking subsystem so that it no longer depends on the "Giant lock"
for proper operation. Removing the use of Giant will improve
performance and permit multiple instances of the network stack to
operate concurrently on multiprocessor systems.</p>
<p>This project started in August. The emphasis has been on locking the
"lower half" of the networking code so that packet forwarding through the
IPv4 path can operate without the Giant lock as part of the 5.2 release.
To this end locking was added to several network interface drivers and
much of the "middleware" code in the network was locked (e.g. ipfw,
dummynet, then routing table, multicast routing support, etc). Work
towards this goal is still ongoing but should be ready for 5.2. A
variety of test systems have been running for several months without the
Giant lock in the network drivers and IP layer.</p>
<p>Past the 5.2 release Giant will be removed from the "upper half" of the
network subsystem and the socket layer. Once this is done the plan is to
measure and improve performance (though some work of this sort is always
happening). The ultimate goal is a system that performs at least as well
as 4.x for normal use on uniprocessor systems. On multiprocessor systems
we expect to see significantly better performance than 4.x due to greater
concurrency and reduced latency.</p>
</body>
</project>
</report>

1156
en/news/status/report-mar-2004-apr-2004.xml
View file

File diff suppressed because it is too large Load diff

2173
en/news/status/report-mar-2005-june-2005.xml
View file

File diff suppressed because it is too large Load diff

1450
en/news/status/report-may-2002-june-2002.xml
View file

File diff suppressed because it is too large Load diff

1107
en/news/status/report-may-2004-june-2004.xml
View file

File diff suppressed because it is too large Load diff

881
en/news/status/report-nov-2002-dec-2002.xml
View file

@ -1,881 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-nov-2002-dec-2002.xml,v 1.5 2004/04/07 11:27:47 phantom Exp $ -->
<report>
<date>
<month>November-December</month>
<year>2002</year>
</date>
<section>
<title>Introduction:</title>
<p>At long last, FreeBSD 5.0 is here. Along with putting the final
polish on the tree, FreeBSD developers somehow found the time to
work on other things too. IA64 took some major steps towards
working on the Itanium2 platform, an effort was started to
convert all drivers to use busdma and ban vtophys(), hardware
crypto support and DEVD hit the tree, NewReno was fixed and
effort began on locking down the network layer of the kernel.
Also high performance, modular scheduler started taking shape
and will be a welcome addition to the kernel soon.</p>
<p>Looking forward, the focus will be on stabilizing and
improving the performance of 5.0. The RELENG_5 (aka 5-STABLE)
branch will be created once we've reached our goals in this
area, so hopefully we will get there quickly. Meanwhile,
preparations for the next release from the 4.x series, 4.8,
will begin soon. Of course, the best way to get 5.x to
stabilize os to install and run it!</p>
<p>Thanks,</p>
<p>Scott Long, Robert Watson</p>
</section>
<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>
<links>
<url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url>
<url href="http://bluez.sf.net">Linux BlueZ stack</url>
<url href="http://sourceforge.net/projects/openobex">OpenOBEX</url>
</links>
<body>
<p>I'm very pleased to announce that all kernel modules and few userland
tools made it to the FreeBSD source tree. Many thanks to Julian
Elischer.</p>
<p>Unfortunately no big changes since the last report. Some minor problems
have been discovered and patches are available on request. I will prepare
all the patches and submit them to Julian for review.</p>
<p> OBEX server and client (based on OpenOBEX library) is almost complete.
I'm currently doing interoperability testing. If anyone has hardware and
time please contact me. The HCI security daemon has been implemented and
tested with Sony Ericsson T68i cell phone and Windows stack. It is now
possible to setup secure Bluetooth connections.</p>
<p>A few people have complained about RFCOMM daemon. These individuals want
to use GPRS and Bluetooth enabled cell phone to access Internet. If you
have this problem please contact me for possible workaround. My next goal
is to get robust RFCOMM implementation to address all these issues.</p>
</body>
</project>
<project>
<title>TrustedBSD Project: Access Control Lists</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<common>TrustedBSD Discussion List</common>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD Project</url>
</links>
<body>
<p>Largely bug-fixing and userland application tweaks; new
interfaces were added to manipulate ACLs on extended attributes;
bugs were fixed in ls relating to ACL flagging. Patches to
teach cp, mv, gzip, bzip, and other apps about ACL preservation
are in testing and review. tunefs flags were added to ease
configuration of ACLs, especially on UFS2 file systems.</p>
<p>Possible changes to make use of Linux/Solaris umask semantics
are under consideration: right now we implement verbatim
POSIX.1e/IRIX merging of the umask, ACL mask, and requested
creation mode during file, device, fifo, and directory creation.
Solaris and the most recent Linux patches ignore the umask in
the context of a default ACL; this requires some rearrangement
of umask handling in our VFS, although the results would be
quite useful. We're exploring how to do this in a low impact
way.</p>
</body>
</project>
<project>
<title>TrustedBSD Project: MAC Framework</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<common>TrustedBSD Discussion List</common>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD Project</url>
</links>
<body>
<p>Framework changes:</p>
<p>Instrument KLD system calls (module and kld load, unload, stat)
Instrument NFSd system call. Instrument swapoff(2).
Instrument per-architecture privileged parts of sysarch().
Make use of condition variables to allow callers to wait for the
framework to "unbusy" when loading/unloading policies, rather than
returning EBUSY. Store mount pointer in devfs_mount structure for
use by policies. Improve handling of labels in loopback interface
"re-align" packet copy case. Provide full paths on devfs object
creations to help policies label them properly (not merged).
Experimentation with moving MAC labels into m_tags (not merged).
NFS server now uses real ucreds, not hacked up ucreds,
meaning we can start laying the groundwork for enforcement on
NFS operations. (not merged)</p>
<p>Policy changes</p>
<p>LOMAC: mac_lomac replaces lomac (LOMAC now uses the MAC Framework),
SEBSD: Improved support for devfs labeling based on SELinux genfs.
Handling of hard link checks. Support export of process transition
information for login and others using sysctl. Login now prompts
for roles. Allow policy reload. TTY labeling. Locking adaptation
from Linux. Many, many policy adaptations and fixes. We can
now boot in enforcing mode! mac_bsdextended: fix a bug in which
VAPPEND wasn't mapped to VWRITE, so opens with the O_APPEND bug
failed improperly.</p>
<p>Userland changes</p>
<p>setfmac(8) now supports a setfsmac(8) execution mode, which accepts
initial labeling specification files. Supports an SELinux compatibility
mode so it can accept SELinux label specfiles using the SEBSD module.
sendmail(8) now sets user labels as part of the context switch for mail
delivery.</p>
<p>Documentation changes</p>
<p>Man page updates for MAC command line tools, modules, admin hints, etc.
Updates to the FreeBSD Developer's Handbook chapter on MAC policies
and entry points. MAC section in FreeBSD Handbook.</p>
</body>
</project>
<project>
<title>busdma driver conversion project</title>
<contact>
<person>
<name>
<given>Maxime</given>
<common>Henrion</common>
</name>
<email>mux@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/busdma/" />
</links>
<body>
<p>This project has been coming along pretty well. The amd(4) and
xl(4) drivers have now been converted to use the busdma API,
sparc64 got the bus_dmamap_load_mbuf() and bus_dmamap_load_uio()
functions, and the gem(4) and hme(4) drivers have been updated
to use bus_dmamap_load_mbuf() instead of bus_dmamap_load().</p>
<p>A lot more still needs to be done, as shown on the project's
page. A fair number of conversions are on their way though,
and we can expect a fair number of drivers to be converted
soon, thanks to all the developers who are working on this
project.</p>
</body>
</project>
<project>
<title>FreeBSD C99 &amp; POSIX Conformance Project</title>
<contact>
<person>
<name>
<given>Mike</given>
<common>Barcroft</common>
</name>
<email>mike@FreeBSD.org</email>
</person>
<person>
<name>
<common>FreeBSD-Standards Mailing List</common>
</name>
<email>standards@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/c99/" />
<url href="http://people.FreeBSD.org/~schweikh/posix-utilities.html" />
</links>
<body>
<p>The POSIX Utility Conformance in FreeBSD list (link above) has
been updated to reflect current reality. Not much work remains
to complete base utility conformance.</p>
<p>On the API front, grantpt(), posix_openpt(), unlockpt(),
wordexp(), and wordfree() were implemented. The header
&lt;wordexp.h&gt; was added.</p>
<p>There are currently about 40 unassigned tasks on our project's
status board ranging from documentation, utilities, to kernel
hacking. We would encourage any developers looking for something
to work on to check out the status board and see if anything
interests them.</p>
</body>
</project>
<project>
<title>Hardware Crypto Support Status</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The goal of this project is to import the OpenBSD kernel-level crypto
subsystem. This facility provides kernel- and user-level access to
hardware crypto devices for the calculation of cryptographic hashes,
ciphers, and public key operations. The main clients of this facility
are the kernel RNG (/dev/random), network protocols (e.g. IPsec), and
OpenSSL (through the /dev/crypto device).</p>
<p>This work will be part of the 5.0 release and has been committed to
the -stable source tree for inclusion in the 4.8 release.</p>
<p>Recent work has focused on improving performance. System statistics are
now maintained and an optional profiling facility was added for
analyzing performance. Using this facility the overhead for using the
crypto API has been significantly reduced.</p>
<p>The ubsec (Broadcom) driver was changed to significantly improve
performance under load. In addition several memory leaks were fixed in
the driver and the public key support was enabled for use.</p>
<p>Upcoming work will focus on load-balancing requests across multiple
crypto devices and integrating OpenSSL 0.9.7 which will automatically
enable application use of crypto hardware.</p>
</body>
</project>
<project>
<title>DEVD</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Devd has been integrated into FreeBSD 5.0-RELEASE. The
integrated code supports a range of configuration options. The
config files are fully parsed now and their actions are
performed.</p>
<p>Future work in this area is likely to be limited to improving
the devctl interface. /dev/devctl likely will be a cloneable
device in future versions. Individual device control via devctl
is also planned.</p>
</body>
</project>
<project>
<title>Donations Team Status Report</title>
<contact>
<person>
<name>
<given>Michael</given>
<common>Lucas</common>
</name>
<email>donations@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/donations/">Donations main page</url>
<url href="http://www.FreeBSD.org/donations/wantlist.html">FreeBSD
developer wantlist</url>
<url href="http://www.FreeBSD.org/donations/donors.html">
completed donations</url>
</links>
<body>
<p>The Donations project expedited several dozen donations during
2002, and was able to place most of what was offered. We still
are in dire need of SMP and Sparc systems. You can see
information on our needs and donations that have been handled by
the team on the donations web page.</p>
<p>We are relying increasingly upon the developer wantlist to
place items offered to the Project, and using the commit
statistics to help place items. As such, active committers who
ask for what they want beforehand have a decent chance of
getting it. Less active committers, and committers who do not
ask for what they want, will be lower in our priorities but will
not be excluded.</p>
<p>We are in the process of streamlining the tax deduction process
for donations, and hope to have news on that shortly. We are
also always working to accelerate and reduce our internal
processes, to get the most equipment in the hands of the most
people as quickly as possible.</p>
<p>I especially want to thank David O'Brien and Tom Rhodes for
stepping up and making the team far more successful. Also, the
FreeBSD Foundation has been quite helpful in handling
tax-deductible contributions.</p>
</body>
</project>
<project>
<title>Fast IPsec Status</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The main goal of this project is to modify the IPsec protocols to use
the kernel-level crypto subsystem imported from OpenBSD (see elsewhere).
A secondary goal is to do general performance tuning of the IPsec
protocols.</p>
<p>This work will be part of the 5.0 release. Performance has been improved
due to work on the crypto subsystem.</p>
</body>
</project>
<project>
<title>FFS volume label support</title>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordon@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~gordon/patches/volume.diff">Current patch set.</url>
</links>
<body>
<p>The goal of the project is to use a small amount of space in the FFS
superblock to store a volume label of the user's choice. A GEOM module
will then expose the volume labels into a namespace in devfs. The idea
is to make it easier to manage filesystems across disk swaps and
movement from system to system.</p>
<p>At this point, everything pretty much works. I've submitted parts of
the patch to respective subsystem maintainers for review. There are some
issues with namespace collision that I haven't addressed yet, but the
basic functionality is there</p>
</body>
</project>
<project>
<title>French FreeBSD Documentation Project</title>
<contact>
<person>
<name>
<given>Sebastien </given>
<common>Gioria</common>
</name>
<email>gioria@FreeBSD.org</email>
</person>
<person>
<name>
<given>Marc </given>
<common>Fonvieille</common>
</name>
<email>blackend@FreeBSD.org</email>
</person>
<person>
<name>
<given>St&#233;phane</given>
<common>Legrand</common>
</name>
<email>stephane@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd-fr.org">The French FreeBSD Documentation Project.</url>
<url href="http://www.freebsd-fr.org/index-trad.html">The FreeBSD Web Server translated in French.</url>
<url href="http://people.FreeBSD.org/~blackend/doc/fr_FR.ISO8859-1/books/handbook/"> Translation of the hanbook.</url>
<url href="http://www.FreeBSD-fr.info">French Daemon News like web site.</url>
</links>
<body>
<p>Most of the articles are translated too. Marc is still translating the
handbook, 60% is currently translated. St&#233;phane has began the
integration of our French localization web site in the US CVS Tree.
S&#233;bastien is still maintaining the Release Notes.</p>
<p>We launched a new site, www.FreeBSD-fr.info, consisting in a French
Daemon News like site. Netasq have donated our new server; we will
install it in a new hosting provider in the few next weeks. One of the
big job now is the translation of the FAQ, and the big
project will be the manual pages.</p>
</body>
</project>
<project>
<title>FreeBSD GNOME Project</title>
<contact>
<person>
<name>
<given>Joe</given>
<common>Marcus</common>
</name>
<email>marcus@FreeBSD.org</email>
</person>
<person>
<name>
<given>Maxim</given>
<common>Sobolev</common>
</name>
<email>sobomax@FreeBSD.org</email>
</person>
<person>
<name>
<given>Adam</given>
<common>Weinberger</common>
</name>
<email>adamw@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
Homepage.</url>
</links>
<body>
<p>Since the ports tree has been frozen for most of this reporting period,
there have not been too many GNOME updates going into the official CVS
tree. However, development has not stopped. GNOME 2.2 is nearing
completion, and quite a few FreeBSD users have stepped up to test the
GNOME 2.1 port sources from the
<a href="http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi">MarcusCom
CVS repository</a>. If anyone else is interested, follow the
instructions on the aforementioned cvsweb URL, and checkout the "ports"
module.</p>
<p>The upcoming FreeBSD 5.0-RELEASE will be the first release to have the
GNOME 2.0 desktop as the default GNOME desktop choice. During the
previously mentioned ports freeze, all the GNOME 2 ports were fixed up
so that they build and package on both i386 and Alpha platforms. Alas,
the one port that will not make the cut for Alpha is Mozilla. There are
still problems with the xpcom code, but work is ongoing to get a working
Alpha port.</p>
<p>Finally, the FreeBSD Mono (an OpenSource C&#35; runtime) port has also
received some new life. Mono has been updated to 0.17 (the latest
released version), and Juli Mallett has ported gtk-sharp (GTK+ bindings
for C&#35;).</p>
</body>
</project>
<project>
<title>FreeBSD/ia64 Status</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Wemm</common>
</name>
<email>peter@FreeBSD.org</email>
</person>
<person>
<name>
<given>Marcel</given>
<common>Moolenaar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~peter/ia64.diff" />
<url href="http://www.FreeBSD.org/platforms/ia64/" />
</links>
<body>
<p>The ia64 port is up and running on the new Itanium2 based hp
machines thanks to a lot of hard work by Marcel Moolenaar. So
far we are running on the hp rx2600 as these were the machines
graciously donated by Hewlett-Packard and Intel. We had a
prototype Intel Tiger4 system for a while, but we had to return
the machine and we do not know if it currently runs. Most of
the changes necessary to run these are sitting in the perforce
tree and are not in the -current or RELENG_5 cvs tree. As a
result, the cvs derived builds (-current and the 5.0-RC series
and presumably 5.0-RELEASE) are only usable on obsolete Itanium1
systems.</p>
<p>Lots of other stability and functionality fixes have been made
over the last few months, including initial libc_r support. The
OS appears to be stable enough for sustained workloads - it is
building packages now, for example. We still do not have gdb
support, even for reading core files.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
</links>
<body>
<p>We have been updating our Japanese translated manual pages to
RELENG_5 based. All existing entries have been updated, but 15
exceptions are not, most of which require massive update. We
will also need to add translations which did not exist on RELENG_4.</p>
</body>
</project>
<project>
<title>KGI/FreeBSD Status Report</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/ggiport.html" />
<url href="http://www.kgi-project.org" />
</links>
<body>
<p>KGI (Kernel Graphic Interface) is a kernel infrastructure providing user
applications with means to access hardware graphic resources (dma,
irqs, mmio). KGI is already available under Linux as a separate
standalone project. The KGI/FreeBSD project aims at integrating KGI
in the FreeBSD kernel.</p>
<p>KGI/FreeBSD has been recently donated 2 PCI graphic cards (Matrox
Millenium II and a coming Mach64) and other have been proposed.
Please see the FreeBSD web pages for details. Thanks to donation@ for
organizing and promoting donations. Thanks to the donators for their
contribution to KGI/FreeBSD.</p>
<p>KGI/FreeBSD progressed fine the last months. Most of the VM issues for
mapping HW resources in user space have been addressed and a first
attempt of coding was made. This prototyping raised some API
compatibility problems with the current Linux implementation and was
discussed heavily on the kgi devel lists. Ask if you're
interested in such issues, I'll be pleased to share them.</p>
<p>Most of coding is now done. Let's start debugging!</p>
</body>
</project>
<project>
<title>SMP locking for network stack</title>
<contact>
<person>
<name>
<given>Jeffrey</given>
<common>Hsu</common>
</name>
<email>hsu@FreeBSD.org</email>
</person>
</contact>
<body>
<p> Work is ongoing to continue to lock up the network stack.
Recently, the focus has been on the IP stack. The plan there
involves a series of inter-related pieces to lock up the
ifaddr ref count, the inet list, the ifaddr uses, the ARP code,
the routing tree, and the routing entries. We are over 3/5 of
the way done down this path.</p>
<p>In addition to TCP and UDP, the other networking protocols
such as raw IP, IPv6, AppleTalk, and XNS need to be locked up.
Around 1/4 these remaining protocols have been locked and
will be committed after the IP stack is locked.</p>
<p>The protocol independent socket layer needs to be locked and
operating correctly with the protocol dependent locks. This
part is mostly done save for much needed testing and code cleanup.</p>
<p>Finally, a pass will be need to be made to lock up the devices drivers
and various statistics counters.</p>
</body>
</project>
<project>
<title>TCP congestion control</title>
<contact>
<person>
<name>
<given>Jeffrey</given>
<common>Hsu</common>
</name>
<email>hsu@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>This effort fixes some outstanding problems in our TCP
stack with regard to congestion control. The first
item is to fix our NewReno implementation. Following that,
the next urgent correction is to fix a problem involving window updates
and dupack counts. When that stabilizes, we will then change
the recovery code to make use of SACK information.
Eventually, this project will update the BSD stack to add Limited Transmit
and other new internet standards and standards-track improvements.</p>
</body>
</project>
<project>
<title>FreeBSD Package Cluster work</title>
<contact>
<person>
<name>
<given>Kris</given>
<common>Kennaway</common>
</name>
<email>kris@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://bento.FreeBSD.org/" />
</links>
<body>
<p>The 3 FreeBSD package clusters (i386, alpha, sparc64) have been
unified to run from the same master machine, instead of using 3
separate masters. This has freed up some machine resources to
use as additional client machine, as well as simplifying
administrative overheads. Build logs for all 3 architectures
can now be found on the http://bento.FreeBSD.org webpage. The
sparc64 package cluster now has 3 build machines (an u5 and two
u10s), and an ia64 cluster is about to be created.</p>
<p>Package builds now keep track of how many sequential times a
port has failed to build (html summaries are available on the
bento website). This allows tracking of ports which have
suddenly become broken (e.g. due to a bad upgrade, or due to
changes in the FreeBSD source tree), and in the future will be
used to send out notifications to port maintainers when their
port fails to build 5 times in a row. This feature is currently
experimental, and further code changes will be needed to
stabilize it.</p>
</body>
</project>
<project>
<title>Wireless Networking Status</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The goal of this project is to improve the wireless networking support in
the system. By the time of this report the 802.11 link layer code should
be committed. A version of the wi driver that uses this code should be
committed shortly. Conversion of other drivers is planned as are drivers
for new devices.</p>
<p>Support for 802.1x/EAP is the next planned milestone (both as a
supplicant and authenticator).</p>
</body>
</project>
<project>
<title>FreeBSD Release Engineering</title>
<contact>
<person>
<name>
<given>Scott</given>
<common>Long</common>
</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/releng/index.html">Release Engineering
Homepage</url>
</links>
<body>
<p>November and December were especially busy for the release engineering
team. Scott Long joined the team to help with secretary and
communications tasks while Brian Somers bowed out to focus on other
projects.</p>
<p>FreeBSD 5.0-DP2 was released in November after much delay and
anticipation, and marked the final milestone needed for 5.0 to
become a reality. Shortly after that, we imposed a code freeze on
the HEAD branch of CVS and released 5.0-RC1. Creation of the
RELENG_5_0 branch came next, followed by the release of 5.0-RC2 from
this branch. At this point, enough critical problems still existed
that we scheduled an RC3 release for the new year, and pushed the
final 5.0-RELEASE date to mid-January. By the time this is published,
FreeBSD 5.0-RELEASE should be a reality.</p>
<p>For the time being, there will not be a RELENG_5 (aka 5-STABLE)
branch. FreeBSD 4.x releases will continue, with 4.8 being
scheduled for March 2003. Release in the 4.x series will be
lead by Murray Stokely, and releases in the 5.x series will be
lead by Scott Long. Once HEAD has reached acceptable performance
and stability goals, the RELENG_5 branch will be created and HEAD
will move towards 6.0 development. We hope to reach this with
the 5.1 release this spring.</p>
</body>
</project>
<project>
<title>SMP aware scheduler</title>
<contact>
<person>
<name>
<given>Jeff</given>
<common>Roberson</common>
</name>
<email>jeff@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A new scheduler will be available as an optional component along side
the current scheduler in the 5.1 release. It has been designed to
work well with KSE and SMP. Some ideas have been borrowed from solaris
and linux along with many novel approaches. It has O(1) performance
with regard to the number of processes in the system. It also has
cpu affinity which should provide a speed boost for many applications.</p>
<p>The scheduler has a few loose ends and lots of tuning before it is
production quality although it is quite stable. Please see the post
to arch and subsequent discussion for more details.</p>
</body>
</project>
</report>

1029
en/news/status/report-november-2001.xml
View file

File diff suppressed because it is too large Load diff

1365
en/news/status/report-oct-2003-dec-2003.xml
View file

File diff suppressed because it is too large Load diff

1370
en/news/status/report-oct-2005-dec-2005.xml
View file

File diff suppressed because it is too large Load diff

2546
en/news/status/report-oct-2006-dec-2006.xml
View file

File diff suppressed because it is too large Load diff

1025
en/news/status/report-sept-2002-oct-2002.xml
View file

File diff suppressed because it is too large Load diff

948
en/news/status/report-september-2001.xml
View file

@ -1,948 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-september-2001.xml,v 1.3 2004/04/04 21:46:14 phantom Exp $ -->
<report>
<date>
<month>September</month>
<year>2001</year>
</date>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS"
version="1.0">
<cvs:keyword name="freebsd">$FreeBSD: www/en/news/status/report-september-2001.xml,v 1.3 2004/04/04 21:46:14 phantom Exp $</cvs:keyword>
</cvs:keywords>
<section>
<title>Introduction</title>
<p>In the month of September, the FreeBSD Project continued its
investment in long-term projects, including continuing work on a
fine-grained SMP implementation, support for Kernel Schedulable
Entities (KSE) supporting highly efficient threading, and
broadening support for modern hardware platforms, including Intel's
new IA64 architecture, UltraSparc, and PowerPC. Additional focus
was placed on the release process, including work on the release
notes infrastructure, support for DVD releases, and work on a
binary updating tool.</p>
<p>Due to the delay in getting the September report out the door,
the November status report will also cover October. During the
month of November, we look forward to BSDCon Europe, the first such
event outside the continental United States. The USENIX conference
paper submission deadlines are also in November, and FreeBSD users
and developers are encouraged to submit to the general and FREENIX
tracks. Please see www.usenix.org for more information.</p>
</section>
<project>
<title>PRFW</title>
<contact>
<person>
<name>
<given>Evan</given>
<common>Sarmiento</common>
</name>
<email>evms@csa.bu.edu</email>
</person>
</contact>
<links>
<url href="http://www.freesoftware.fsf.org/jailuser/" />
</links>
<body>
<p>PRFW provides hooks in the FreeBSD kernel, allowing users to
insert their own checks in system calls and various kernel
functions. PRFW is nearing 0.5, which will incorporate numerous
structural changes such as, much faster per-process hooks, kernel
function hooks, plus, a new way of adding hooks which would
enable users to reference hooks by a string.</p>
</body>
</project>
<project>
<title>FreeBSD libh Project</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Langer</common>
</name>
<email>alex@FreeBSD.org</email>
</person>
<person>
<name>
<given>Nathan</given>
<common>Ahlstrom</common>
</name>
<email>nra@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/libh.html" />
</links>
<body>
<p>The build process is now creating four different versions of
the libs, which include support for TVision, Qt, both or none. I
created some first packages from existing ports and installed
those libh packages on my system only using libh's tools,
including registering all the files in the package database,
recording their checksums etc. Patches to the disk editor have
been submitted, which include functionality to write the changes
in the fdisk part and initial support for a disk label editor.
We'll soon have a new committer.</p>
</body>
</project>
<project>
<title>RELNOTESng</title>
<contact>
<person>
<name>
<given>Bruce A.</given>
<common>Mah</common>
</name>
<email>bmah@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~bmah/relnotes/" />
</links>
<body>
<p>FreeBSD 4.4-RELEASE was the first release of FreeBSD with its
new-style release documentation. Both English and Japanese
versions of these documents were created. Regularly-built
snapshots of -CURRENT and 4-STABLE release documentation are now
available on the Web site, but they require a little HTML
infrastructure to make them viewer-friendly. I intend to continue
updating my snapshot site at the URL above, at least for a little
while.</p>
<p>Call for help: The hardware compatibility lists need to be
updated in the areas of the Alpha architecture, USB devices, and
PCCARD devices. I'm looking for volunteers to help; interested
parties should contact me at the email address above. DocBook
experience is not required; familiarity with the hardware above
would be very helpful.</p>
</body>
</project>
<project>
<title>Fibre Channel Support</title>
<contact>
<person>
<name>
<given>Matthew</given>
<common>Jacob</common>
</name>
<email>mjacob@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.feral.com/isp.html" />
</links>
<body>
<p>Bug fixing and move to -STABLE of 2Gb support.</p>
</body>
</project>
<project>
<title>Intel Gigabit Ethernet</title>
<contact>
<person>
<name>
<given>Matthew</given>
<common>Jacob</common>
</name>
<email>mjacob@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Quite a lot of cleanup of this driver. Bug fixes and some
performance enhancements. However, this driver is likely to be
removed shortly and replaced by one from Intel itself.</p>
</body>
</project>
<project>
<title>TIRPC</title>
<contact>
<person>
<name>
<given>Martin</given>
<common>Blapp</common>
</name>
<email>mb@imp.ch</email>
</person>
</contact>
<links>
<url href="http://www.attic.ch/tirpc.html" />
</links>
<body>
<p>As you know, in march 2001 the version 2.3 of TIRPC has been
committed together with many userland changes. Alfred Perlstein
and Ian Dowse have helped me a lot with the porting effort and if
I had problems with understanding the code.</p>
<p>Most bugs are now fixed, some remaining areas to fix are
secure RPC (keyserv) and unix domain support. I've patches for
these area available. Ian Dowse fixed a lot of outstanding bugs
in the rpcbind binary itself. Thank you Ian !</p>
<p>The plan is now to migrate slowly towards TIRPC 2.8, which is
threadsafe for the server- and clientside. One first patch I've
made available on my URL. TIRPC 2.8 is licensed under the "Sun
Standards License Version 1.0" and we have to add some license
lines and the license itself to all modified files.</p>
<p>A example is timed_clnt_create.diff which can be found on the
homepage.</p>
</body>
</project>
<project>
<title>binup</title>
<contact>
<person>
<name>
<given>Eric</given>
<common>Melville</common>
</name>
<email>eric@FreeBSD.org</email>
</person>
<person>
<name>
<given>Murray</given>
<common>Stokely</common>
</name>
<email>murray@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/updater.html" />
</links>
<body>
<p>The project has gained a mailing list,
freebsd-binup@FreeBSD.org - and the source tree has been moved
into the projects/ directory in the FreeBSD CVS repository.
Current work is focusing on extending the FreeBSD package
framework, and the client library should be rewritten and
completed by the end of the year.</p>
<p>TODO: make the projects/ hierarchy into a cvsup distribution
and add it to cvs-all. Then update distrib.self.</p>
</body>
</project>
<project>
<title>Porting ppp to hurd &amp; linux</title>
<contact>
<person>
<name>
<given>Brian</given>
<common>Somers</common>
</name>
<email>brian@freebsd-services.com</email>
</person>
</contact>
<body>
<p>Status is unchanged since last month. Patches have been
submitted to get ppp working under HURD, and mostly under Linux.
There are GPL copyright problems that need to be addressed. Many
conflicts are expected after the commit of IPv6 support in
ppp.</p>
</body>
</project>
<project>
<title>PPP IPv6 Support</title>
<contact>
<person>
<name>
<given>Brian</given>
<common>Somers</common>
</name>
<email>brian@freebsd-services.com</email>
</person>
</contact>
<body>
<p>The software has been committed to -current and seems
functional. Outstanding issues include dealing with IPV6CP events
(linkup &amp; linkdown scripts) and allocating site-local and
global addresses (currently, ``iface add'' is the only way to
actually use the link). A bug exists in -stable (running the
not-yet-MFC'd ppp code) whereby routing entries are disappearing
after a time (around 12 or 24 hours). No further details are yet
available.</p>
</body>
</project>
<project>
<title>FreeBSD DVD generation</title>
<contact>
<person>
<name>
<given>Brian</given>
<common>Somers</common>
</name>
<email>brian@freebsd-services.com</email>
</person>
</contact>
<body>
<p>A two disc set has been mastered and sent for pressing. There
are a few surprises with this release - details will be given in
the official announcement (at BSDConEurope).</p>
</body>
</project>
<project>
<title>Netgraph ATM</title>
<contact>
<person>
<name>
<given>Harti</given>
<common>Brandt</common>
</name>
<email>brandt@fokus.gmd.de</email>
</person>
</contact>
<body>
<p>ATM-Forum LAN-emulation version 2.0 without support for QoS
has been implemented and tested. The ILMI daemon has been
modularized into a general mini-SNMP daemon, an ILMI module and a
not yet finished IPOA (IP over ATM) module.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<email>man-jp@jp.FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/" />
</links>
<body>
<p>We have finished updating section [125678] manpages to
4.4-RELEASE based, 1 week after 4.4-RELEASE is announced. To
finish this update, OKAZAKI Tetsurou has imported Ex/Rv macro
support on ja-groff-1.17.2_1. SUZUKI Koichi did most Ex/Rv
changes on Japanese manpages. He also find some issues of these
macro usage on some original manpages and filed a PR. For
post-4.4-RELEASE, now we target 4.5-RELEASE. Section 3 update is
also in progress.</p>
</body>
</project>
<project>
<title>New Mount(2) API</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
<person>
<name>
<given>Maxime</given>
<common>Henrion</common>
</name>
<email>mux@qualys.com</email>
</person>
</contact>
<body>
<p>We've made some good progress now, and the new nmount(2)
syscall is nearly finished. There is still some work to do to
have a working kernel_mount() and to convert all filesystems to
use this new API for their VFS_MOUNT() functions.</p>
</body>
</project>
<project>
<title>FreeBSD/sparc64 port</title>
<contact>
<person>
<name>
<given>Jake</given>
<common>Burkholder</common>
</name>
<email>jake@FreeBSD.org</email>
</person>
<person>
<name>
<given>Thomas</given>
<common>Moestl</common>
</name>
<email>tmm@FreeBSD.org</email>
</person>
</contact>
<body>
<p>I am pleased to announce that as of 1 AM Friday October 19th,
the sparc64 port boots to single user mode. A few binaries from
the base system have been built and verified to work properly.
Much of this work is still in review for commit, but will be
integrated into the cvs tree as soon as possible. EBus support
has been ported from NetBSD, and ISA support has been written.
The PCI host bridge code has stabilized, and busdma seems to work
correctly now. The sio driver has had EBus support added, and the
ATA driver has been modified so that it works on big-endian
systems and uses the busdma API. With these changes, a root file
system can now be successfully mounted from ATA disks on sparc64,
even in DMA mode. The gem driver, which supports Sun GEM and ERI
and Apple GMAC and GMAC2 ethernet adaptor, has been ported from
NetBSD but has not yet had sufficient testing.</p>
</body>
</project>
<project>
<title>SYN cache implementation for FreeBSD</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>No new status to report, the code is still waiting to be
committed. It is likely that this code will be expanded to
include syn cookies as a further fallback mechanism.</p>
</body>
</project>
<project>
<title>Compressed TCP state</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Development on this project has been slowed, pending the
commit of the syncache code, as this builds on part of that
work.</p>
</body>
</project>
<project>
<title>Network SMP locking</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Not much progress has been made this month, with other
projects occupying most of my time. However, reviewing all the
code and data structures had a side benefit; a hash table for
inet addresses has been added. This will significantly speed up
interface address lookups in the case where there are a larger
number of interface aliases.</p>
</body>
</project>
<project>
<title>Multiple console support</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Currently, a single device may act as a console at any time,
which requires the user to choose the console device at boot
time. With the upcoming network console support, it is desirable
to allow multiple console devices which behave identically, and
to alter consoles while the kernel is running.</p>
<p>The code is completed, and needs some final polishing to clean
up the rough edges. Console output can be sent to both syscons
and sio, (as well as the network) and when in ddb, input can be
taken from any input source. A small control program allows
adding and removing consoles on the fly.</p>
</body>
</project>
<project>
<title>Network console</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>This project's goal is to add low level network functionality
to FreeBSD. The initial target is to make a network console
available for remote debugging with ddb or gdb. A secondary
target is to utilize the code to perform network crash dumps. The
design assumes that the network card and driver are working, but
does not rely on other parts of the kernel.</p>
<p>Initial development has been fairly rapid, and a minimal
TCP/IP stack has been written. It is currently possible to telnet
to a machine which is at the ddb&gt; prompt and interact with the
debugger.</p>
</body>
</project>
<project>
<title>Network device nodes</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Network devices now support aliases in the form of /dev/netN,
where N is the interface index. Devices may be wired down to a
specific index number by entries in /boot/device.hints of
either:</p>
<p>hint.net.&lt;ifindex&gt;.dev="devname"
hint.net.&lt;ifindex&gt;.ether="ethernet address"</p>
<p>Additionally, ifconfig has been updated so that it will accept
the alias name when configuring a device.</p>
</body>
</project>
<project>
<title>Intel Gigabit driver</title>
<contact>
<person>
<name>
<given>Jonathan</given>
<common>Lemon</common>
</name>
<email>jlemon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The gx driver has finally been committed to the tree. The
driver provides support for the Intel PRO/1000 cards, both fiber
and copper variants. The driver supports VLAN tagging and TCP/IP
checksum offload.</p>
</body>
</project>
<project>
<title>KSE</title>
<contact>
<person>
<email>julian@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~jasone/kse/" />
<url href="http://www.FreeBSD.org/~julian" />
</links>
<body>
<p>In the last month, not a lot has happened other than settling
in of the big August commit. Largely due to me having a sudden
increased workload at work, and a need for increased time to be
spent elsewhere. However some design work has proceeded. The API
has firmed up somewhat and several people have been reading
through what has been done already in order to be able to help in
the next phase.</p>
<p>Milestone 3 will be to have the ability to generate and remove
multiple threads/KSEs per process. Milestone 3 will NOT require
that doing so will be safe. (especially in SMP systems), i.e.
locking issues will not be fully addressed, so while some testing
will be possible, it will not be possible to actually run in this
mode with any load.</p>
<p>This will require allocators and destructors for the new
structures. Creation of the syscalls. Generation of an accurate
written API for the userland crew. Writing of the upcall launch
code. Production of a userland test program (not a full thread
scheduler). Resolution of some of the more glaring
incompatibilities (e.g. the scheduler) in a backwards compatible
manner. (i.e. if there are no multi threaded processes on a
system it should behave the same as now (and be as
reliable)).</p>
<p>Criteria for knowing when we have reached Milestone 3 is the
ability for a simple process on an unloaded system to perform a
series of blocking syscalls reliably. e.g. open 2 sockets, and
send data on one, after having done a read on another, and then
'respond' in like manner..</p>
</body>
</project>
<project>
<title>PowerPC Port</title>
<contact>
<person>
<name>
<given>Benno</given>
<common>Rice</common>
</name>
<email>benno@FreeBSD.org</email>
</person>
</contact>
<body>
<p>There have been a few major successes in the PowerPC port this
month. Mark Peek has succeeded in getting the FreeBSD/PowerPC
kernel cross compiled on FreeBSD and booting under the PSIM
simulator (now in /usr/ports/emulators/psim-freebsd). I have
succeeded in getting the FreeBSD loader to load and execute
kernels using the OpenFirmware found on Apple Macintosh hardware.
Mark is now working on completing some of the startup and pmap
code, while I am taking advantage of the simulator to work on
some interrupt and device issues.</p>
</body>
</project>
<project>
<title>FreeBSD Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@eyesbeyond.com</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/java/">Official FreeBSD Java
Project site.</url>
</links>
<body>
<p>The project has moved forward on JDK 1.3.1 development this
month, with the release of two more patchsets. The team is
reasonably confident that the latest patchset is a stable release
of the core JDK 1.3.1 tools and classes, when the default "green"
threads subsystem is used. This is mostly thanks to hard work by
Fuyuhiko Maruyama to stabilize and fix the code. Bill Huey has
also been progressing with his work on the "native" threads
subsystem, although this hasn't yet reached the stability of
"green" threads. Another (arguably the) major highlight of the
latest patchset was the integration of NetBSD support by Scott
Bartram and Alistair Crooks (the latter of NetBSD packages fame).
Hopefully OpenBSD support will follow, making it truly a united
BSD Java Project.</p>
</body>
</project>
<project>
<title>Improving FreeBSD startup scripts</title>
<contact>
<person>
<name>
<given>Doug</given>
<common>Barton</common>
</name>
<email>DougB@FreeBSD.org</email>
</person>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordont@gnf.org</email>
</person>
</contact>
<links>
<url href="http://groups.yahoo.com/group/FreeBSD-rc/">Improving
FreeBSD startup scripts</url>
<url href="http://www.cs.rmit.edu.au/~lukem/bibliography.html">
Luke Mewburn's papers</url>
<url href="http://www.netbsd.org/Documentation/rc/">NetBSD
Initialization and Services Control</url>
</links>
<body>
<p>This group is for discussion about the startup scripts in
FreeBSD, primarily the scripts in /etc/rc*. Primary focus will be
on improvements and importation of NetBSD's excellent work on
this topic.</p>
<p>Alright folks, I finally got off my butt last night and put
together a roadmap for the migration to the new rc.d init scripts
that were imported from NetBSD a long time ago and just sat in
the tree.</p>
<p>M1 (Patch included)
<br />
Setup infrastructure
<br />
Make rcorder compile
<br />
Hook rc.subr into the distribution (and mergemaster)
<br />
Hook rcorder into the world
<br />
Add toggle in rc.conf to switch between rc_ng and current boot
scripts</p>
<p>M2
<br />
Get FreeBSD to boot with the new boot scripts
<br />
Rewrite the /etc/rc.d scripts to work with FreeBSD</p>
<p>M3
<br />
Add some FreeBSD specific support into rc.subr</p>
<p>M4
<br />
Add true dependency checking to the infrastructure so that
starting nfsd will start mountd and rpcbind
<br />
add support into rc.subr
<br />
Add dependencies into rc.d scripts</p>
<p>I'd like a couple of people to take a look at this and then
I'll submit a pr for it if there aren't too many objections. I'm
expecting M2 to run into quite a bikeshed, but hey, I got my nice
shiny asbestos back from the cleaners.</p>
</body>
</project>
<project>
<title>FreeBSD C99/POSIX Conformance Project</title>
<contact>
<person>
<name>
<given>Mike</given>
<common>Barcroft</common>
</name>
<email>mike@FreeBSD.org</email>
</person>
<person>
<name>
<common>FreeBSD-Standards Mailing List</common>
</name>
<email>freebsd-standards@bostonradio.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~mike/c99/" />
</links>
<body>
<p>The FreeBSD C99/POSIX Conformance Project aims to implement
all requirements of the C99 Standard and the latest 1003.1-200x
POSIX draft (currently Draft 7). In cases where aspects of the
standard cannot be followed, those aspects will be documented in
the c99(7) or posix(7) manuals. It is also an aim of this project
to implement regression tests to ensure correctness whenever
possible.</p>
<p>Patches that implement the &lt;stdint.h&gt; and
&lt;inttypes.h&gt; headers, and modifications to printf(3) have
been developed and will be committed shortly. They will allow us
to use some of the new types C99 introduces, such as intmax_t and
the printf(3) conversion specifier "%j".</p>
</body>
</project>
<project>
<title>SMPng Status Report</title>
<contact>
<person>
<name>
<given>John</given>
<common>Baldwin</common>
</name>
<email>jhb@FreeBSD.org</email>
</person>
<person>
<email>smp@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~jasone/smp/" />
</links>
<body>
<p>Some progress has been made on the proc locking this month.
Also, a new LOCK_DEBUG macro was defined to allow some locking
infrastructure to be more efficient. Kernels now only include the
filenames of files calling mutex, sx, or semaphore lock
operations if the filenames are needed. Also, mutex operations
are no longer inlined if any debugging options are turned on. The
ucred API was also overhauled to be more locking friendly. A
group has also started investigating the tty subsystem to design
and possibly implement a locking strategy.</p>
</body>
</project>
</report>

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

@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD: www/en/news/status/status.sgml,v 1.42 2007/04/10 03:35:31 brd Exp $">
<!ENTITY date "$FreeBSD: www/en/news/status/status.sgml,v 1.43 2007/04/10 15:12:08 brd Exp $">
<!ENTITY title "FreeBSD Quarterly Status Reports">
<!ENTITY % navinclude.about "INCLUDE">
]>
@ -41,85 +41,85 @@
<h2>2007</h2>
<ul>
<li><a href="report-2007-jan-2007-mar.html">January, 2007 -
<li><a href="report-2007-01-2007-03.html">January, 2007 -
March, 2007</a></li>
</ul>
<h2>2006</h2>
<ul>
<li><a href="report-oct-2006-dec-2006.html">October, 2006 -
<li><a href="report-2006-10-2005-12.html">October, 2006 -
December, 2006</a></li>
<li><a href="report-june-2006-oct-2006.html">June, 2006 -
<li><a href="report-2006-06-2006-10.html">June, 2006 -
October, 2006</a></li>
<li><a href="report-apr-2006-jun-2006.html">April, 2006 -
<li><a href="report-2006-04-2006-06.html">April, 2006 -
June, 2006</a></li>
<li><a href="report-jan-2006-mar-2006.html">January, 2006 -
<li><a href="report-2006-01-2006-03.html">January, 2006 -
March, 2006</a></li>
</ul>
<h2>2005</h2>
<ul>
<li><a href="report-oct-2005-dec-2005.html">October, 2005 -
<li><a href="report-2005-10-2005-12.html">October, 2005 -
December, 2005</a></li>
<li><a href="report-july-2005-oct-2005.html">July, 2005 -
<li><a href="report-2005-07-2005-10.html">July, 2005 -
October, 2005</a></li>
<li><a href="report-mar-2005-june-2005.html">March, 2005 -
<li><a href="report-2005-03-2005-06.html">March, 2005 -
June, 2005</a></li>
<li><a href="report-jan-2005-mar-2005.html">January, 2005 -
<li><a href="report-2005-01-2005-03.html">January, 2005 -
March, 2005</a></li>
</ul>
<h2>2004</h2>
<ul>
<li><a href="report-july-2004-dec-2004.html">July, 2004 -
<li><a href="report-2004-07-2004-12.html">July, 2004 -
December, 2004</a></li>
<li><a href="report-may-2004-june-2004.html">May, 2004 -
<li><a href="report-2004-05-2004-06.html">May, 2004 -
June, 2004</a></li>
<li><a href="report-mar-2004-apr-2004.html">March, 2004 -
<li><a href="report-2004-03-2004-04.html">March, 2004 -
April, 2004</a></li>
<li><a href="report-jan-2004-feb-2004.html">January, 2004 -
<li><a href="report-2004-01-2004-02.html">January, 2004 -
February, 2004 </a></li>
</ul>
<h2>2003</h2>
<ul>
<li><a href="report-oct-2003-dec-2003.html">October, 2003 -
<li><a href="report-2003-10-2003-12.html">October, 2003 -
December, 2003 </a></li>
<li><a href="report-mar-2003-sep-2003.html">March, 2003 -
<li><a href="report-2003-03-2003-09.html">March, 2003 -
September, 2003 </a></li>
<li><a href="report-jan-2003-feb-2003.html">January, 2003 -
<li><a href="report-2003-01-2003-02.html">January, 2003 -
February, 2003 </a></li>
</ul>
<h2>2002</h2>
<ul>
<li><a href="report-nov-2002-dec-2002.html">November, 2002 -
<li><a href="report-2002-11-2002-12.html">November, 2002 -
December, 2002 </a></li>
<li><a href="report-sept-2002-oct-2002.html">September, 2002 -
<li><a href="report-2002-09-2002-10.html">September, 2002 -
October, 2002 </a></li>
<li><a href="report-july-2002-aug-2002.html">July, 2002 - August, 2002
<li><a href="report-2002-07-2002-08.html">July, 2002 - August, 2002
</a></li>
<li><a href="report-may-2002-june-2002.html">May, 2002 - June, 2002
<li><a href="report-2002-05-2002-06.html">May, 2002 - June, 2002
</a></li>
<li><a href="report-feb-2002-apr-2002.html">February, 2002 - April,
<li><a href="report-2002-02-2002-04.html">February, 2002 - April,
2002</a></li>
<li><a href="report-dec-2001-jan-2002.html">December, 2001 - January,
<li><a href="report-2001-12-2002-01.html">December, 2001 - January,
2002</a></li>
</ul>
<h2>2001</h2>
<ul>
<li><a href="report-november-2001.html">November, 2001</a></li>
<li><a href="report-september-2001.html">September, 2001</a></li>
<li><a href="report-august-2001.html">August, 2001</a></li>
<li><a href="report-july-2001.html">July, 2001</a></li>
<li><a href="report-june-2001.html">June, 2001</a></li>
<li><a href="report-2001-11.html">November, 2001</a></li>
<li><a href="report-2001-09.html">September, 2001</a></li>
<li><a href="report-2001-08.html">August, 2001</a></li>
<li><a href="report-2001-07.html">July, 2001</a></li>
<li><a href="report-2001-06.html">June, 2001</a></li>
</ul>
&footer;

14
share/sgml/news.xml
View file

@ -20,7 +20,7 @@
<news>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
$FreeBSD: www/share/sgml/news.xml,v 1.72 2007/04/10 03:35:31 brd Exp $
$FreeBSD: www/share/sgml/news.xml,v 1.73 2007/04/10 06:03:06 brd Exp $
</cvs:keyword>
</cvs:keywords>
@ -35,7 +35,7 @@
<title>January-March, 2007 Status Report</title>
<p>The January-March, 2007 Status Report is <a
href="&base;/news/status/report-2007-jan-2007-mar.html">now
href="&base;/news/status/report-2007-01-2007-03.html">now
available</a> with 19 entries.</p>
</event>
</day>
@ -274,7 +274,7 @@
<title>October-December, 2006 Status Report</title>
<p>The October-December, 2006 Status Report is <a
href="&base;/news/status/report-oct-2006-dec-2006.html">now
href="&base;/news/status/report-2006-10-2006-12.html">now
available</a> with 41 entries.</p>
</event>
</day>
@ -567,7 +567,7 @@
<title>June-October, 2006 Status Report</title>
<p>The June-October, 2006 Status Report is <a
href="&base;/news/status/report-june-2006-oct-2006.html">now
href="&base;/news/status/report-2006-06-2006-10.html">now
available</a> with 49 entries.</p>
</event>
</day>
@ -737,7 +737,7 @@
<title>April-June 2006 Status Report</title>
<p>The April-June, 2006 status report is <a
href="&base;/news/status/report-apr-2006-jun-2006.html">now
href="&base;/news/status/report-2006-04-2006-06.html">now
available</a> with 39 entries.</p>
</event>
</day>
@ -1053,7 +1053,7 @@ href="http://wiki.freebsd.org/moin.cgi/SummerOfCode2006">Summer of Code wiki</a>
<title>January-March 2006 Status Report</title>
<p>The January-March, 2006 status report is <a
href="&base;/news/status/report-jan-2006-mar-2006.html">now
href="&base;/news/status/report-2006-01-2006-03.html">now
available</a> with 29 entries.</p>
</event>
@ -1261,7 +1261,7 @@ href="http://wiki.freebsd.org/moin.cgi/SummerOfCode2006">Summer of Code wiki</a>
<title>October-December 2005 Status Report</title>
<p>The October-December, 2005 status report is <a
href="&base;/news/status/report-oct-2005-dec-2005.html">now
href="&base;/news/status/report-2005-10-2005-12.html">now
available</a> with 26 entries.</p>
</event>
</day>