doc/en/news/status/report-2002-05-2002-06.xml
2002-08-14 19:36:47 +00:00

1445 lines
44 KiB
XML

<report>
<date>
<month>May - June</month>
<year>2002</year>
</date>
<section>
<title>Introduction</title>
<p>May and June were remarkably busy months for the FreeBSD Project--
FreeBSD developers met in Monterey, CA in June for FreeBSD
Developer Summit III to discuss strategy for the FreeBSD 5.0
release later this year, for the USENIX Annual Technical
conference and for the FreeBSD BoF. Substantial technical progress
was made on FreeBSD 5.0, and FreeBSD 4.6-RELEASE was cut on the
RELENG_4 branch in June.</p>
<p>The remainder of the summer will continue to be busy. Final
components and features for 5.0-RELEASE will go into the tree,
and the development direction will change from new features
to stability, performance, and production-readiness. With
additional 5.0 development previews late in the summer, we
hope to broaden the tester base for the -CURRENT branch,
and start to get early adopters digging out any potential
problems in their test environments. I encourage both FreeBSD
Developers and FreeBSD Users to give 5.0-DP2 a spin (on a machine
without critical data!) and let us know how it goes. The more
testing that happens before the release, the less fixing we have
to do afterwards!</p>
<p>Robert Watson</p>
</section>
<project>
<title>TCP Hostcache</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
</contact>
<body>
<p>The current cache for the TCP metrics is embedded directly into
the routing table route objects. This is highly inefficient as every
route has an empty 56 Byte large metrics structure in it. TCP is the
only consumer (except the MTU and Expiry field) of the structure. A
full view of the Internet routes (110k routes) has more than 6 Mbyte
of unused overhead due to it. The hit rate today is at only approx.
10% in webserver applications. The TCP hostcache will move this entire
metrics structure from the routing table to the TCP stack. Every entry
is a host entry so a simple hash table is sufficient to keep the
entries. Its implementation is much like the TCP Syncache.</p>
<p>The hostcache is going through testing on our servers and will
be ready for committing in September. The results of the TCP metrics
measurement will be used to tune the cache.</p>
</body>
</project>
<project>
<title>IP Routing Table Replacement</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
<person>
<name>
<given>Claudio</given>
<common>Jeker</common>
</name>
<email>jeker@n-r-g.com</email>
</person>
</contact>
<body>
<p>The current Patricia Trie routing table in BSD UNIX is not very
efficient and wastes an enormous amount of space for every node (more
than 256 bytes) (A full Internet view of 110k routes takes 33 MByte
of KVM). Another problem are pointers from and to everywhere
in the routing table. This makes replacing the table very hard and
also significantly highers the table maintainance burden (for example
for some kinds of updates the entire PCB has be searched lineary).
Also this is a heavy burden for SMP locking. The rewrite focuses on
untangeling the pointer mess, making the routing table replaceable
and providing a more IP optimized table (5 MByte for 110k routes).
Other new options include policy routing and some structual alignments
in the network stack for clarity, cleaness and flexibilty.</p>
<p>The rewritten IP routing table will be ready for committing in
October.</p>
</body>
</project>
<project>
<title>TCP Metrics Measurement</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
<person>
<name>
<given>Olivier</given>
<common>Mueller</common>
</name>
<email>omueller@8304.ch</email>
</person>
</contact>
<links>
<url href="http://www-t.zhwin.ch/pa02_2/diplomarbeiten2002.pdf">
Diploma Thesis of ZHWIN students, look for Olivier Mueller and Daniel
Graf</url>
</links>
<body>
<p>These students will analyse the tcpdumps of five major Swiss
newspaper websites which give a representative overview of the
user structure in Switzerland. The nice thing about Switzerland
is that is has a very good mix of Modem/ISDN, leased line, Cable,
ADSL and 3G/GSM/GPRS users. Every Internet access technology is
represented. The goal is to analyse the behaviour of all TCP
sessions to the monitored sites. Parameters to be analysed include
TCP session RTT, RTT variance, in/outbound BDP, MSS changes, flow
control behaviour, packet loss, packet loss, packet retransmit and
timing of HTTP traffic to find optimal TCP parameter caching
method.</p>
<p>If you have any other metrics you think is useful please contact
me so I can put that into the job description for the Students. The
study will be made in September and October.</p>
</body>
</project>
<project>
<title>NATD rewrite</title>
<contact>
<person>
<name>
<given>Claudio</given>
<common>Jeker</common>
</name>
<email>jeker@n-r-g.com</email>
</person>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
</contact>
<body>
<p>The current natd is pretty powerful in translating different kinds
of traffic but not very powerful in configuration. This project
rewrites natd and parts of libalias to give it a configuration set as
powerful and expressive as the ones in ipf (ipnat) and pf. In addition
it'll use kqueue and will support aliasing to multiple IP
addresses.</p>
<p>The rewritten natd will be ready for committing in early
September.</p>
</body>
</project>
<project>
<title>FreeBSD/ia64</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Wemm</common>
</name>
<email>peter@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~peter/ia64/">IA64 project
updates and information.</url>
</links>
<body>
<p>IA64 has been progressing slowly. We have access to a prototype
4-way Itaninum2 system from Intel and have managed to get it up and
running to the point of being able to access disk and network with
SMP enabled. We have a big problem with ACPI2.0 and PCI routing
table entries behind pci-pci bridges with no short-term solution
in sight. Various WIP items have been committed to CVS, namely
more complete support for executing 32bit i386 binaries as well
as Marcel Moolenaar's prototype EFI GPT tools.</p>
</body>
</project>
<!-- $FreeBSD: www/en/news/status/report-may-2002-june-2002.xml,v 1.3 2002/08/14 18:45:04 rwatson Exp $ -->
<project>
<title>Libh Status Report</title>
<contact>
<person>
<name>
<given>Antoine</given>
<common>Beaupre</common>
</name>
<email>antoine@usw4.freebsd.org</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Langer</common>
</name>
<email>alex@freebsd.org</email>
</person>
</contact>
<contact>
<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" />
<url href="http://usw4.freebsd.org/~libh/">libh
new development web page.</url>
<url href="http://usw4.freebsd.org/~libh/screenshots">
First snapshots of the diskeditor in action</url>
</links>
<body>
<p>Max has been busy cleaning up the user interface dark side, and has
come up with a plan to improve the build system (using an automated
Makefile dependency generator); the UI design and the TCL glue magic
(using Swig). A develepment page has been created on usw4, publishing
a lot of information about the current project status, a Changelog,
screenshots, documentation, etc. A new listbox widget has been
implemented, making diskeditor look nicer and more useable. The package
system backend is being inspected and redesigned to conform to a standard
that is itself being re-thought. Indeed, the old sysinstall2.txt text has
been SGML-ized and enhanced and now provides a good (altough rough) overview
of libh package system. This allowed the document to be enhanced with diagrams
of how different procedures work. We are therefore getting closer to a
real pkgAPI specification document. The package management tools have been
sligthly enhanced and should be a bit more useable, and we started commiting
regression test suites in the tree, mostly to test and maintain pkg API
conformance.</p>
<p>So work continues on libh. I plan to take a look at the rhtvision port
to see if it would be better to use it for the tvision backend. I'll keep
on working on the package system to make it really trustworthy, while Max
is continuing his great work on the UI subsystem. I hope to make a new libh
alpha release soon. Note that from now on, libh progress will be published
on the development page.</p>
</body>
</project>
<project>
<title>OLDCARD</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A major power bug was fixed in oldcard. This caused many
problems for people using PCI interrupts having their machines hang on
boot. This fix has made it into 4.6.1.</p>
<p>Cardbus power is now used on all cardbus bridges that support
it. This means that we now support 3.3V cards on all cardbus
bridges. Before, we only supported them on some of the bridges
because every bridge uses different 3.3V power control when programmed
through the ExCA registers. Now that we're going through the CardBus
bridge's power control register, 3.3V cards work. In fact, for
CardBus bridges, the so called X.XV and Y.YV cards will work in those
bridges that support them. However, X.XV and Y.YV haven't been
defined yet, and no bridges support them (but the bridge interface
define it). Obviously this latter part is untested.</p>
<p>CL-PD6722 support has been augmented slightly. Now it is
possible to instruct the driver which type of 3.3V card detection
strategy to use. There are three choices: none, do it like the
CL-PD6710 does it and do it like the CL-PD6722 does it.</p>
<p>Preliminary support for the CL-PD6729 on a PCI card using PCI
interrupts has been committed. However, it fails for at least one of
the cards like this the author has.</p>
<p>Client drivers can now ask for the manufacturer and model
number of the card without parsing the CIS directly.</p>
<p>Except for fixing bugs and updating pccard.conf entries, no
additional work is planned on the OLDCARD system.</p>
</body>
</project>
<project>
<title>NEWCARD</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A devd daemon, to replace pccardd and usbd, has been designed.
A few minor bugs have been fixed in NEWCARD. NEWCARD is now the
default in -current. There is an experimental pci/cardbus bus code
merge available as a branch which will be merged into current as soon
as it is stable.</p>
<p>Status: The ed driver, for non-ne2000 clones, is broken and won't
probe. The ata driver won't attach. The sio driver hangs on the
first character. The wi driver is known to work well. Cardbus cards
are generally known to work well, except for some de based cards,
which unfortuntely includes the popular Xircom cards. Many systems
fail to work because acpi fails to route interrupts correctly for
non-root pci bridges.</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>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.freebsd.org/gnome/">FreeBSD GNOME Project
Homepage.</url>
</links>
<body>
<p>Things are going well with the FreeBSD GNOME Project. We have just
finished porting the GNOME 2.0 Final development platform and desktop
to FreeBSD! We hope to be able to make GNOME 2.0 the default for
5.0-DP2 and 4.7-RELEASE. In the meantime, we're working to port more
GNOME 2.0 applications.</p>
<p>In order to allow GNOME 1.4.1 applications to work with GNOME 2.0,
we are revamping the GNOME porting infrastructure. GNOME 1.4.1 based
ports are being converted to use the new GNOMENG porting structure.
The specifics of this new system will be written up in the GNOME
porting guide found on the FreeBSD GNOME project homepage.</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>
<!-- A hypertext link with a description... -->
<url href="http://www.freebsd.org/java/">FreeBSD Java Project</url>
</links>
<body>
<p>
The BSD Java Porting Team has been making slow but steady progress
on a number of fronts in the last few months. Unfortunately most
of this has occurred behind the scenes, meaning this is a good
opportunity to bring the community up to date.
<ul>
<li>Bill Huey has gotten the Java HotSpot Virtual Machine up and
running on FreeBSD! While dubbing the code of alpha quality,
Bill has been working hard and is able to run major examples
such as the Java 2D demo. This code has hit the repository
and will soon be available.</li>
<li>The port of the 1.4 J2SDK has commenced. The first commits
have gone into the tree, although a first patchset is a
way off yet.</li>
<li>Progress continues with the TCK compliance testing. The
current status has the JDK down to 19 compiler failures
and 183 runtime failures. As we edge closer to compliance
its hoped that example code will be released to allow the
community to pull together through the final few bugs.</li>
<li>A new patchset for JDK 1.3.1 is imminent. This patchset
will include HotSpot for the first time.</li>
</ul>
</p>
</body>
</project>
<project>
<title>KAME Project</title>
<contact>
<person>
<name>
<given>SUZUKI</given>
<common>Shinsuke</common>
</name>
<email>core@kame.net</email>
</person>
</contact>
<links>
<url href="http://www.kame.net/">KAME Project Web Page</url>
<url href="http://www.interop.jp/eng/exhibition/ipv6_showcase.html">IPv6 Showcase at Network+Interop2002</url>
<url href="http://www.interop.jp/jp/exhibition/ipv6_showcase.html">IPv6 Showcase at Network+Interop2002 (detailed, but in Japanase)</url>
<url href="http://www.sfc.wide.ad.jp/~say/n+i/">Pictures of IPv6 Showcase</url>
</links>
<body>
<p>I'm afraid KAME Project does not work actively with regard to FreeBSD in these two month, since
we are too busy with the demonstration of our IPv6 implementation at Networld+Interop 2002 Tokyo.
(Thanks to a great effort, the demonstration was quite successful) </p>
<p>We are aware of netinet6-related bug reports regarding socket handling, fine-grain locking, ip6fw etc.
Regret to say, we could not answer them right now due to the above situation, however we'll discus
these issues internally and determine what to do. </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>
<url href="http://www.usenix.org/events/bsdcon03/cfp/">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>FreeBSD Release Engineering</title>
<contact>
<person>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/releng" />
</links>
<body>
<p>Over the past few months the FreeBSD Release Engineering Team
oversaw a release process that culminated in the release of
FreeBSD 4.6 for the i386 and Alpha architectures on June 15.
The RE team is currently working concurrently on FreeBSD 4.6.1
and 5.0 DP2. 4.6.1 is a minor point release with an updated SSH
and BIND, fixes for some of the reported ata(4) problems, and
assorted security enhancements that will be detailed in the
release notes. The release engineering activities for 4.6.1 are
taking place on the RELENG_4_6 branch in CVS, while the work on
5.0 DP2 is taking place in Perforce so as not to disturb ongoing
-CURRENT development. We are still committed to FreeBSD 5.0 on
or around November 15, 2002. For more information about
upcoming release schedules, please see our website above. The
RE team would like to thank Sentex Communications for providing
the release builders with access to a fast i386 build machine.
Compaq also donated a couple of fast Alpha build machines to the
project.</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>Basic functionality is operational for IPv4 protocols. IPv6 support is
coded but not yet tested. Hardware assisted cryptographic operations are
working with good performance improvements. Operation with software-based
cryptographic calculations appears to be at least as good as the existing
implementation. Numerous opportunities for performance improvements have
been identified.</p>
<p>This work is currently being done in the -stable tree. A port to
the -current tree is about to start.</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/" />
</links>
<body>
<p>Since the last status report, the following utilities have been
brought up to conformance (at least to some degree) with POSIX.1-2001,
they include: asa(1), cd(1), compress(1), ctags(1), ls(1), newgrp(1),
nice(1), od(1), pathchk(1), renice(1), tabs(1), tr(1), uniq(1), wc(1),
and who(1). In addition, development is taking place on bringing the
BSD SCCS suite up to date with newer standards.</p>
<p>On the API front, printf(9) has been given support for the `j' and
'n' flags, waitpid(2) now supports the WCONTINUED option, and an
implementation of fstatvfs() and statvfs() has been committed. An
implementation of utmpx is in progress, which has an aim to address
some of the major problems with the current utmp. Several headers
have been brought up to conformance with POSIX.1-2001, they include:
&lt;netinet/in.h&gt;, &lt;pwd.h&gt;, &lt;sys/statvfs.h&gt;, and
&lt;sys/wait.h&gt;.</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>The software has been available as a patch against the -stable tree for
about six months. The core crypto support is tested, including device
drivers for the Hifn 7951, and Broadcom 5805, 5820, and 5821 parts. Recent
work has concentrated on fixing device driver bugs, fixing support for Hifn
7811 parts, adding support for public key operations, and adding
flow-control between the crypto layer and device drivers. Future work
includes porting this facility to the -current tree.</p>
</body>
</project>
<project>
<title>KSE (Kernel schedulable Entity) thread support </title>
<contact>
<person>
<name>
<given>Julian</given>
<common>Elischer</common>
</name>
<email>julian@FreeBSD.org</email>
</person>
<person>
<name>
<given>Dan</given>
<common>Eischen</common>
</name>
<email>deischen@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.freebsd.ord/~julian/">Some info
here.</url>
</links>
<body>
<p>
The project took a major step at the beginning of July when
Milestone-III was committed. Milestone-III allows a simple test
program (available at /usr/src/tools/KSE/ksetest/)
to run multiple threads, using kernel support. It does not yet
allow the ability to allow these threads to run on different CPUs
simultaneously. Milestone IV will be to allow this, however
Milestone-III should allow Dan to start (with any interested
parties) to start prototyping the userland part of the
system. Milestone-III is only currently usable on x86, and
does not include some of the
requirements for full thread-control, suspension etc. that
will be required later. </p>
<p>
Before M-IV is started some small tweeking is likely
in the central sources on M-III as we discover issues
as we try to get the userland jumpstarted. These will have no
effect on non-KSE processes, (i.e. all of them :-) and
should not be an issue for other developers. </p>
<p>
A tex/fig->html guru is needed to help maintain the
KSE web page (not mentionned above as it is broken).
</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/smp/" />
</links>
<body>
<p>The SMPng project has continued to make steady progress in
the past two months. Jeff Roberson completed the switch over
to UMA for the general kernel malloc() and free() pushing down
Giant appropriately so that callers of malloc() and free() are
no longer required to hold Giant. Alan Cox continues to clean
up the locking in the VM system pushing down Giant in several
of the VM related system calls. Jeffrey Hsu committed locking
for TCP/IP protocol control blocks in the network stack. John
Baldwin committed the changes to the p_canfoo() API to use
thread credentials for subject threads and added appropriate
locking for the targer process credentials. Support for
adaptive mutexes on SMP systems as well as the new IA32 PAUSE
instruction were also committed in May. The kernel tracing
facility KTRACE also received an overhaul such that the
majority of its work was pushed out into a worker thread
allowing trace points to no longer require Giant. Andrew
Reiter has also been pushing down Giant in several system
calls.</p>
<p>Bosko continues to work on light-weight interrupt threads
for i386. Most of the bugs in the turnstile code have been
found and fixed; however, the turnstile and preemption
patches have temporarily been put on hold so that more
emphasis can be placed on fixing bugs and making -current
more stable in preparation for 5.0 release in November.
Alan Cox and Andrew Reiter are continuing the work mentioned
above. Jeff Roberson is also working on fixing the current
vnode locking in VFS. Peter Wemm has also started to tackle
TLB issues on SMP in the i386 pmap again as well.</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>After an outstanding job serving the project as Security Officer
for over a year, Kris stepped down in January in order to focus more
of his time pursuing his PhD. I offered to attempt to fill the vacant
role.</p>
<p>This is the first report by the SO Team. Notable events since
the beginning of 2002 follow.</p>
<p>28 FreeBSD Security Advisories have been issued, 16 of which
were regarding the base system. Of those sixteen, 8 affected only
FreeBSD.</p>
<p>FreeBSD Security Notices were introduced, and four have been
issued so far. The Security Notices cover issues that are not
regarded as critical enough to warrant a Security Advisory. So far
only Ports Collection issues (i.e. vulnerabilities in optional 3rd
party packages) have been reported in Security Notices. The first
four Security Notices covered 53 individual issues.</p>
<p>Issues reported to the SO team are now being tracked using a
RequestTracker ticket database.</p>
<p>The SO team has undergone membership changes, as well as some
changes in internal organization. The membership and organization
has also been made publicly visible on the FreeBSD Security Officer
web page.</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>For 4.6-RELEASE, we announced the package ja-man-doc-4.6.tgz
which is in sync with 4.6-RELEASE base system manual pages
except for perl5 pages (jpman project do not maintain them).
Continuing section 3 updating has 88% finished.</p>
</body>
</project>
<project>
<title>FreeBSD/KGI 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"> Project URL</url>
</links>
<body>
<p>Progression is slow, but the effort is maintained. Most of fb over KGI has been
written in parallel with a KGI display driver based on fb.
DDC/DDC2 is being discussed for Plug &amp; Play monitor support. KGI aims at providing
a generic OS independant interface which would take advantage of FreeBSD I2C (iic(4))
infrastructure.
</p>
</body>
</project>
<project>
<title>UFS2 - Extended attribute and large size support for UFS</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
<person>
<name>
<given>Kirk</given>
<common>Mckusick</common>
</name>
<email>mckusick@FreeBSD.org</email>
</person>
</contact>
<body>
<p>
UFS2 is an extension to the well-known UFS filesystem which
using a new inode format adds support for "64bit everywhere"
and later for extended attribute support, in addition to the
current UFS features: soft-updates and snapshots.
</p>
<p>
The basic UFS2 code has been committed and work on the extended
attribute interface and vnode operations will continue.
</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>
<!-- A hypertext link with a description... -->
<url href="http://www.freebsd.org/~phk/Geom/">Old concept paper here.</url>
</links>
<body>
<p>
The GEOM code has gotten so far that it beats our current code
in some areas while stil lacking in others. The goal is for
GEOM to be the default in 5.0-RELEASE.
</p>
<p>
Currently work on a cryptographic module which should be able
to protect a diskpartition from practically any sort of attack
is progressing.
</p>
</body>
</project>
<project>
<title>OpenOffice.org for FreeBSD</title>
<contact>
<person>
<name>
<given>Martin</given>
<common>Blapp</common>
</name>
<email>mbr@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://projects.imp.ch/openoffice">OpenOffice.org FreeBSD port Homepage</url>
</links>
<body>
<p>The port of openoffice 1.0 has been finished. Most showstopper issues
with rtld, libc and our toolchain have been fixed. There is one remaining
deadlock in the web-browser code of OO.org. If anybody like to help
us with fixing this bug (may be another libc_r bug as it looks like)
just mail me ! Unfortunalty gcc2 support got broken again with the import
of gcc2.95.4 in STABLE. Exceptions support seems to be broken again, we get
internal compiler errors with c++ exceptions code. You'll have to use gcc31
again.</p>
<p>Since our package cluster is outdated and can not build OO.org packages
anytime soon, I did my own little package cluster and can now offer
packages for 4.6R for 16 different languages. They can be found on the
project homepage.</p>
<p>Porting of OpenOffice1.0.1 is on it's way. A beta port and a package have
been made available on the project homepage.</p>
</body>
</project>
<project>
<title>Lightweight Interrupt Scheduling</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/~peter/p4db/chb.cgi?FSPC=//depot/projects/interrupt/sys/...">
The interrupt p4 branch</url>
</links>
<body>
<p>The lightweight interrupt scheduling code makes scheduling an
interrupt on i386 without having to grab the sched_lock possible,
and also avoids a full-blown context switch.</p>
<p>Currently, the code in the p4 branch works, although needs a
little bit of cleanup and, most importantly, requires a merge to
post-KSE III. Now that stuff seems to have stabilized a bit, I'm
waiting to get a little time (and nerve) to do the merge. Also,
looking forward for some KSE interface that will allow for "KSE
borrowing," which would make this cleaner with regards to KSE and
lightweight interrupts. This is a 5.0 feature.</p>
</body>
</project>
<project>
<title>TIRPC port for BSD sockets</title>
<contact>
<person>
<name>
<given>Martin</given>
<common>Blapp</common>
</name>
<email>mbr@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.attic.ch/tirpc">TIRPC for FreeBSD Homepage</url>
<!-- And/or one without. -->
<url href="http://www.attic.ch/tirpc" />
</links>
<body>
<p>
A lot of remaining PR's and Bugs have been closed. All relevant rpc
concerning patches have been comitted. Thank goes to Alfred and Ian Dowese.
</p>
<p>Jean-Luc Richier &lt;Jean-Luc.Richier@imag.fr&gt; has made a patch
available which adds IPv6 support to all remaining rpc servers.
See ftp://ftp.imag.fr/pub/ipv6/NFS/NFS_IPV6_FreeBSD5.0.gz and
ftp://ftp.imag.fr/pub/ipv6/NFS/0README_NFS_IPV6_FreeBSD5.0
We will check his code and add it to CURRENT ASAP.</p>
<p>A first commit part from TIRPC99 has been done. I'm working now
on porting the remaining parts so when FreeBSD 5.0 gets released,
it will be TIRPC99 based. This will happen together with the NetBSD
project, as they use the same codebase as we do.
</p>
</body>
</project>
<project>
<title>mb_alloc updates</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_alloc/">Some
[Old] mb_alloc stuff</url>
</links>
<body>
<p>mb_alloc is getting some updates and a couple of optimisations.
A new allocator interface routine should already be committed by
the time this report is "published:" m_getcl() allocates an mbuf
and a cluster in one shot. This is the result of months
(literally) of requests from Alfred and, recently, Luigi - who,
coincidentally, is the author of the same [upcoming] routine in -STABLE.</p>
<p>Other than that, mb_alloc is being shown how to perform
multi-mbuf or cluster allocations without dropping the cache lock in
between (m_getcl() and m_getm() will use this). Finally, work is
being done to optimise ext_buf ref. count allocations and to provide
support for jumbo (> 9K) clusters.</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>
</contact>
<contact>
<person>
<name>
<given>Mike</given>
<common>Makonnen</common>
</name>
<email>makonnen@pacbell.net</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordont@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://groups.yahoo.com/group/FreeBSD-rc/links/">
The Yahoo! group site for discussion of this project
</url>
</links>
<body>
<p>We are making excellent progress. There is a fully functioning
implementation imported to -current now. We need as many people as
possible to rc_ng equal to YES in /etc/rc.conf.</p>
<p>The next step is to set the default to YES, which we plan to do
before DP 2.</p>
</body>
</project>
<project>
<title>ipfw2</title>
<contact>
<person>
<name>
<given>Luigi</given>
<common>Rizzo</common>
</name>
<email>luigi@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.iet.unipi.it/~luigi/" />
</links>
<body>
<p>In summer 2002 the native FreeBSD firewall has been completely
rewritten in a form that uses BPF-like instructions
to perform packet matching in a more effective way. The external
user interface is completely backward compatible, though you can
make use of some newer
match patterns (e.g. to handle sparse sets of IP addresses) which
can dramatically simplify the writing of ruleset (and speed up
their processing).
The new firewall, called ipfw2, is much faster and easier to
extend than the old one. It has been already included in
FreeBSD-CURRENT, and patches for FreeBSD-STABLE are available
from the author.
</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/">Project Webpage (in Japanese
)</url>
<url href="http://snapshots.jp.FreeBSd.org:8021">SNAPSHOTs anonftp area on the web</url>
<url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD/releases/i386/">Release branch snapshots for FreeBSD/i386</url>
</links>
<body>
<p>
I spent busy days in last two months, many new topics are emerged
from the project. We now support FreeBSD/alpha 5-current
distribution by cross-compiling on the x86 PC. Anonymous ftp area
is now exported to the yet another web server. Our release branch
snapshots are relocated to daemon.jp.FreeBSD.org because of our
CPU/network bandwidth problem.
</p>
<p>
I'm seriously considering to solve the lack of CPU and network
resources for the project's future evolution. Maybe the bandwidth
problem can be resolved (several bandwidth offering are received!),
but there is no answer about CPU problem (I have a plan to upgrade
our PCs from P3-500Mhz to P4 or something better than previous).
If you have interested to donate PCs to the project, please email me
for more detail.
</p>
</body>
</project>
<project>
<title>Userland Regression Tests</title>
<contact>
<person>
<name>
<given>Juli</given>
<common>Mallett</common>
</name>
<email>jmallett@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Regression tests for many bugs fixed in text manipulation utilities
have been added, as well as tests for various non-standard versions
of functionality that FreeBSD users should expect. A library of
m4 macros for creating the tests themselves has been added.</p>
</body>
</project>
<project>
<title>Single UNIX Specification conformant SCCS suite</title>
<contact>
<person>
<name>
<given>Juli</given>
<common>Mallett</common>
</name>
<email>jmallett@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The final version of SCCS distributed by CSRG has been integrated
into the projects CVS repository, and worked on extensively to the
point where essential functionality works on FreeBSD (and other
operating systems). Some standards-related functionality has been
implemented</p>
</body>
</project>
<project>
<title>Zero Copy Sockets status report</title>
<contact>
<person>
<name>
<given>Ken</given>
<common>Merry</common>
</name>
<email>ken@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://people.FreeBSD.org/~ken/zero_copy/">Zero copy patches
and information. </url>
</links>
<body>
<p> The zero copy sockets code was committed to FreeBSD-current on June
25th, 2002. I'm not planning on doing any more patches, although
I will leave the web page up as it contains useful information. </p>
<p>
Many thanks to the folks who have tested and reviewed the code over
the years. </p>
</body>
</project>
<project>
<title>locking up pcb's in the networking stack</title>
<contact>
<person>
<name>
<given>Jeffrey</given>
<common>Hsu</common>
</name>
<email>hsu@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- And/or one without. -->
<url href="http://www.freebsd.org/smp" />
</links>
<body>
<p>Jennifer Yang's patch was committed June 10 for the BSD Summit.
After a few bugs which were reported initially and
fixed that same week, networking in -current
has been stable, including the parts that were not locked up,
like IPv6. Work is on-going to lock up the rest of the stack.</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>
Not much to report. Another engineering snapshot is available
for download at
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020709.tar.gz.
If anyone has Bluetooth hardware and spare time please join in and help
me
with testing.
</p>
<p>
This snapshot includes basic support for USB devices and manual pages.
The HCI layer now has support for multiple control hooks. All HCI
transport
drivers (H4, BT3C and UBT) has been changed to provide consistent
interface
to the rest of the world. Some userspace utilities have been changed as
well.
</p>
<p>
Still no support for RFCOMM (Serial port emulation over Bluetooth link)
and
SDP (Service Discovery Protocol). Several design flaws have been
discovered
and it might take some time to resolve these issues.
</p>
</body>
</project>
<project>
<title>TrustedBSD MAC</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Discussion Mailing List</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD main web page</url>
</links>
<body>
<p>The TrustedBSD Project has been busy in May and June,
developing new features, presenting on the technology at
the FreeBSD Developer Summit, and improving the readiness
of the MAC branch for integration into the main FreeBSD
tree. The migration to dynamic labeling in the TrustedBSD
MAC framework is complete, with all policies now making
use of dynamic labels in the kernel. This permits policies
to associate arbitrary additional security data with a
variety of kernel objects at run-time. Implement mac_test,
a sanity checking module. Pass labels as well as objects
to each policy entry point to reduce knowledge of label
storage in the policies. Implement mac_partition, a simple
jail-like policy. Adapt the MAC framework for process locking.
</p>
<p>
Improve support for sockets: provide a peerlabel maintained for
stream sockets (unix domain, tcp), entry points for accept,
bind, connect, listen. Improve support for IPv4 and IPv6 by
labeling IP fragment reassembly queues, and providing entry
points to instrument fragment matching, update, reassembly, etc.
Locally disable KAME if_loop mbuf contiguity hack because it
drops labels on mbufs: we need to make sure the label is
propagated. Label pipes and provide access control for them.
Improve vnode labeling: now handle labeling for devfs, pseudofs,
procfs. Fix interactions between MAC and ACLs relating to the
new VAPPEND flag.</p>
<p> SELinux policy tools now ported to SEBSD. SEBSD now labels
subjects and file system objects.
Provide ugidfw, a tool for managing rules for the mac_bsdextended
policy.</p>
<p> Massive diff reduction. KSEIII merged. Main tree integration
will begin shortly.</p>
<p>Updated prototype code may be retrieved from the TrustedBSD
CVS trees on cvsup10.FreeBSD.org.</p>
</body>
</project>
</report>