<?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$ -->

<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 increases the table maintenance burden (for example
 for some kinds of updates the entire PCB has to be searched linearly).
 Also this is a heavy burden for SMP locking. The rewrite focuses on
 untangling 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 structural alignments
 in the network stack for clarity, simplicity and flexibility.</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 analyze the behavior of all TCP
 sessions to the monitored sites. Parameters to be analyzed include
 TCP session RTT, RTT variance, in/outbound BDP, MSS changes, flow
 control behavior, 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>

<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 development 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 usable. 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 (although 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
	slightly enhanced and should be a bit more usable, and we started committing
	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 unfortunately 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 tweaking 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 mentioned 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 independent 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 still 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! Unfortunately 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 committed. Thanks go 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 optimizations.
    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 optimize 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 offers have been received!),
  but there is no answer about CPU problems (I have a plan to upgrade
  our PCs from P3-500MHz to P4 or better).
  If you have interested in donating 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>
