<?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>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 completely (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> Volunteers 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>
