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

<report>
  <date>
    <month>January-April</month>

    <year>2005</year>
  </date>

  <section>
    <title>Introduction</title>

    <p>The first quarter of 2005 has been extremely active in both
    FreeBSD-CURRENT and -STABLE. With FreeBSD 5.4 in the final RC stage
    and an anticipated branch of FreeBSD-6 this summer we have seen a lot
    of performance improvements in 5 and a couple of exciting new
    features in 6.</p>

    <p>The report turnout was extremely good and it seems that the
    webform provided by Julian Elischer has made it more enjoyable to
    write reports. Many thanks to Julian for providing this.  We also
    like to get your attention to the open tasks section provided in some
    reports.</p>

    <p>On special note, please take a look at the report about the
    upcoming BSDCan in Ottawa. There will be lots of interesting FreeBSD
    related talks and activities. If you enjoy reading these reports, you
    will love the conference. See you there!</p>

    <p>Thanks to all the reporters, we hope you enjoy reading.</p>
  </section>

  <category>
    <name>proj</name>

    <description>Projects</description>
  </category>

  <category>
    <name>doc</name>

    <description>Documentation</description>
  </category>

  <category>
    <name>kern</name>

    <description>Kernel</description>
  </category>

  <category>
    <name>net</name>

    <description>Network infrastructure</description>
  </category>

  <category>
    <name>bin</name>

    <description>Userland programs</description>
  </category>

  <category>
    <name>arch</name>

    <description>Architectures</description>
  </category>

  <category>
    <name>ports</name>

    <description>Ports</description>
  </category>

  <category>
    <name>vendor</name>

    <description>Vendor / 3rd Party Software</description>
  </category>

  <category>
    <name>misc</name>

    <description>Miscellaneous</description>
  </category>

  <project cat='proj'>
    <title>Secure Updating</title>

    <contact>
      <person>
        <name>
          <given>Colin</given>

          <common>Percival</common>
        </name>

        <email>cperciva@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.daemonology.net/portsnap/" />

      <url href="http://www.daemonology.net/freebsd-update/" />
    </links>

    <body>
      <p>Shortly before the ports freeze for FreeBSD 5.4, I released a
      new version of Portsnap. In addition to being secure and more
      efficient than CVSup, this latest version distributes INDEX,
      INDEX-5, and INDEX-6 files, thereby eliminating the need to run
      "make fetchindex" and ensuring that the ports INDEX will match the
      existing ports tree. In addition, portsnap builds have now moved
      onto hardware managed by the FreeBSD project, thereby sharply
      increasing portsnap's chances of survival if I get hit by a
      bus.</p>

      <p>In early February hardware problems caused both FreeBSD Update
      and Portsnap to stop functioning for a few days, but those were
      resolved thanks to a server donated by layeredtech.com.</p>

      <p>I intend bring Portsnap into the FreeBSD base system before the
      end of the month, followed by FreeBSD Update a few months
      later.</p>
    </body>
  </project>

  <project cat='project'>
    <title>if_bridge from NetBSD</title>

    <contact>
      <person>
        <name>
          <given>Andrew</given>

          <common>Thompson</common>
        </name>

        <email>andy@fud.org.nz</email>
      </person>
    </contact>

    <links>
      <url href="http://www.fud.org.nz/~andy/if_bridge.diff" />
    </links>

    <body>
      <p>This project aims to import the bridging code and interface from
      NetBSD and OpenBSD. The bridge is a cloned interface which can be
      modified by ifconfig and brconfig. It supports assigning an IP
      address directly to the bridge (e.g. bridge0) instead of one of the
      member interfaces, and can be used with tcpdump to inspect the
      bridged packets. The code also supports spanning tree (802.1D) for
      loop detection and link redundancy. Any pfil(9) packet filter can
      be used to filter the bridged packets.</p>
    </body>

    <help>
      <task>Testing performance and functionality against the existing
      bridge code. Testers welcome!</task>
    </help>
  </project>

  <project cat='arch'>
    <title>ARM Support for TS-7200</title>

    <contact>
      <person>
        <name>
          <given>John-Mark</given>

          <common>Gurney</common>
        </name>

        <email>jmg@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.embeddedarm.com/epc/ts7200-spec-h.html">
      TS-7200 Board</url>

      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/jmg/arm&amp;HIDEDEL=NO">
      Perforce Code Location</url>

      <url href="http://people.freebsd.org/~jmg/dmesg.ts7200">FreeBSD/arm
      TS-7200 dmesg output</url>
    </links>

    <body>
      <p>I have been working on getting FreeBSD/arm running on the
      TS-7200. So far the board boots, and has somewhat working ethernet
      (some unexplained packet loss). I can netboot from a FreeBSD/i386
      machine, and I can also mount msdosfs's on CF.</p>
    </body>

    <help>
      <task>Figuring out why some small packets transmit with
      error</task>

      <task>EP93xx identification information to properly attach various
      onboard devices</task>
    </help>
  </project>

  <project cat='ports'>
    <title>Update of the Linux userland infrastructure</title>

    <contact>
      <person>
        <name>
          <given>Alexander</given>

          <common>Leidinger</common>
        </name>

        <email>netchild@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Emulation</given>

          <common>Mailinglist</common>
        </name>

        <email>freebsd-emulation@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>The update to RedHat 8 as discussed in the last status report
      went smoothly (just some minor glitches which got resolved
      fast).</p>

      <p>As a next step a cleanup/streamlining and the possibility of
      overriding the default Linux base is in progress. This depends on
      changes which need at least one testrun on the ports build cluster,
      so the final date for those changes depends upon the availability
      of the cluster resources.</p>
    </body>

    <help>
      <task>Refactoring the common RPM code into bsd.rpm.mk.</task>

      <task>Determining which up-to-date Linux distribution to use as the
      next default Linux base. Important criteria: 
      <ul>
        <li>RPM based (to be able to use the existing
        infrastructure)</li>

        <li>good track record regarding availability of security
        fixes</li>

        <li>packages available from several mirror sites</li>

        <li>available for several hardware architectures (e.g. i386,
        amd64, sparc64; Note: not all architectures have a working
        linuxolator for their native bit with, but as long as there are
        no userland bits available, no motivation regarding writing the
        kernel bits will arise)</li>
      </ul>
      </task>

      <task>Moving the linuxolator userland to an up-to-date version (see
      above).</task>
    </help>
  </project>

  <project cat='bin'>
    <title>Pipe namespace added to portalfs</title>

    <contact>
      <person>
        <name>
          <given>Diomidis</given>

          <common>Spinellis</common>
        </name>

        <email>dds@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.spinellis.gr/blog/20050413/index.html" />
    </links>

    <body>
      <p>A new sub-namespace, called pipe, has been added to portalfs.
      The pipe namespace executes the named command, starting back at the
      root directory. The command's arguments can be provided after the
      command's name, by separating them with spaces or tabs. Files
      opened for reading in the pipe namespace will receive their input
      from the command's standard output; files opened for writing will
      send the data of write operations to the command's standard input.
      The pipe namespace allows us to perform scatter gather operations
      without using temporary files, create non-linear pipelines, and
      implement file views using symbolic links.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Low-overhead performance monitoring for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Joseph</given>

          <common>Koshy</common>
        </name>

        <email>jkoshy@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://people.freebsd.org/~jkoshy/projects/perf-measurement">
      Project home page</url>
    </links>

    <body>
      <p>Many modern CPUs have on-chip performance monitoring counters
      (PMCs) that can be used to count low-level hardware events like
      instruction retirals, branch mispredictions, cache and TLB misses
      and the like. PMC architectures and capabilities vary between CPU
      vendors and between CPU generations from the same vendor, making
      the creation of portable applications difficult. This project
      attempts to provide a uniform API for applications to use, and the
      necessary infrastructure to "virtualize" and manage the available
      PMC hardware resources. The creation of performance analysis tools
      that use this infrastructure is also part of the project's
      goals.</p>

      <p>Work since the last status report:</p>

      <ul>
        <li>Support for Intel
        Pentium-Pro/Pentium-II/Pentium-III/Pentium-M/Celeron style PMCs
        has been added.</li>

        <li>The Pentium-4/HTT machine dependent layer has been
        overhauled.</li>

        <li>A Python language interface to the C library interface pmc(3)
        has been written.</li>

        <li>Many bugs have been fixed and documentation has been
        updated.</li>
      </ul>
    </body>

    <help>
      <task>The code needs to be tested on Intel Pentium-M, Celeron,
      Pentium II and Pentium Pro CPUs.</task>
    </help>
  </project>

  <project cat='proj'>
    <title>GELI - GEOM class for providers encryption</title>

    <contact>
      <person>
        <name>
          <given>Pawel Jakub</given>

          <common>Dawidek</common>
        </name>

        <email>pjd@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sys/geom/eli&amp;HIDEDEL=NO">
      Kernel module.</url>

      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sbin/geom/class/eli&amp;HIDEDEL=NO">
      Userland configuration utility.</url>
    </links>

    <body>
      <p>GELI is a GEOM class used for GEOM providers encryption. I
      decided to work on this, as I needed some feature, which cannot be
      found in similar projects. Here is the list of features, I found
      interesting:</p>

      <ul>
        <li>makes use of crypto(9)</li>

        <li>if there is a crypto hardware available, GELI will run
        cryptography on it automatically; if not, it starts dedicated
        kernel thread and do crypto software work in there</li>

        <li>supports many cryptographic algorithms (AES, Blowfish,
        3DES)</li>

        <li>is able to take key components from many sources at once
        (user entered passphrase, random bits from a file, etc.)</li>

        <li>allows to encrypt root partition</li>

        <li>user will be asked for the passphrase before root file system
        is mounted</li>

        <li>uses "PKCS #5: Password-Based Cryptography Specification
        Version 2.0" for user passphrase protection (optional)</li>

        <li>allows to use two independent keys (e.g. "user key" and
        "company key")</li>

        <li>is fast</li>

        <li>GELI does simple sector-to-sector encryption</li>

        <li>allows to backup/restore Master Keys, so when user have to
        quickly destroy keys, it is able to get the data back by
        restoring keys from the backup</li>

        <li>provider can be configured at attach time to automatically
        detach on last close (so user don't have to remember to detach
        after unmounting file system)</li>

        <li>allows to attach provider with a random, one-time keys</li>

        <li>useful for swap partitions and temporary file systems</li>
      </ul>
    </body>

    <help>
      <task>Code audit/review is more than welcome!</task>
    </help>
  </project>

  <project cat='doc'>
    <title>FreeBSD Dutch Documentation Project</title>

    <contact>
      <person>
        <name>
          <given>Remko</given>

          <common>Lodder</common>
        </name>

        <email>remko@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/doc/nl/books/handbook">FreeBSD
      Dutch Handbook</url>

      <url href="http://www.evilcoder.org/freebsd_html/">FreeBSD Dutch
      Handbook preview</url>

      <url href="http://www.evilcoder.org/content/section/6/39/">The
      Project Page</url>
    </links>

    <body>
      <p>The FreeBSD Dutch Documentation Project is a ongoing project in
      translating the English documentation to the Dutch language.
      Currently we have translated almost the entire handbook, and more
      to come. If you want to help out by review the Dutch documents, or
      you want to help translating the remainders of the handbook or
      other documents, feel free to contact me at 
      <a href="mailto:remko@FreeBSD.org">remko@FreeBSD.org</a>
      </p>
    </body>

    <help>
      <task>Translate the English handbook, then review the Dutch
      handbook</task>

      <task>Translate the English FAQ, then review the Dutch FAQ</task>

      <task>Translate the English Articles, then review the Dutch
      Articles</task>
    </help>
  </project>

  <project cat='proj'>
    <title>FreeBSD Java Project</title>

    <contact>
      <person>
        <name>
          <given>Greg</given>

          <common>Lewis</common>
        </name>

        <email>glewis@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Alexey</given>

          <common>Zelkin</common>
        </name>

        <email>phantom@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/java/" />
    </links>

    <body>
      <p>The FreeBSD Java Project released its initial support for JDK
      1.5.0 with patch set 1 "Sabretooth" in January. The initial release
      featured support for both FreeBSD 5.3/i386 and 5.3/amd64. Since
      then preliminary support for FreeBSD 4.11/i386 has been added and
      several bug fixes have been made. Updates in the coming months will
      add support for the browser plug in and Java Web Start, which were
      not in the initial release.</p>
    </body>

    <help>
      <task>Volunteers to look into some serious problems with JDK 1.5.0
      on FreeBSD 4.x</task>
    </help>
  </project>

  <project cat='proj'>
    <title>Common Address Redundancy Protocol - CARP</title>

    <contact>
      <person>
        <name>
          <given>Max</given>

          <common>Laier</common>
        </name>

        <email>mlaier@FreeBSD.org</email>
      </person>
    </contact>

    <contact>
      <person>
        <name>
          <given>Gleb</given>

          <common>Smirnoff</common>
        </name>

        <email>glebius@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://www.freebsd.org/cgi/man.cgi?query=carp&amp;manpath=FreeBSD+6.0-current" />

      <url href="http://people.freebsd.org/~mlaier/CARP/" />
    </links>

    <body>
      <p>CARP is an alternative to VRRP. In contrast to VRRP it has full
      support for IPv6 and uses crypto to protect the advertisements. It
      was developed by OpenBSD due to concerns that the HSRP patent might
      cover VRRP and CISCO might defend its patent. CARP has, since then,
      improved a lot over VRRP.</p>

      <p>CARP has been committed to HEAD and MFCed to RELENG_5. It will
      be available in upcoming 5.4-RELEASE.</p>

      <p>Big thanks to all users who provided testing and reported bugs
      to Max and Gleb. Daniel Seuffert has donated hardware to Max for
      this project. Gleb's work was sponsored by 
      <a href="http://www.rambler.ru">Rambler</a>

      .</p>
    </body>

    <help>
      <task>Improve vlan(4) support. Test ng_eiface(4).</task>

      <task>Improve locking, consider removing interface layer.</task>
    </help>
  </project>

  <project cat='net'>
    <title>netgraph(4) status report</title>

    <contact>
      <person>
        <name>
          <given>Gleb</given>

          <common>Smirnoff</common>
        </name>

        <email>glebius@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://www.freebsd.org/cgi/man.cgi?query=ng_netflow&amp;manpath=FreeBSD+6.0-current">
      ng_netflow(4)</url>

      <url
      href="http://www.freebsd.org/cgi/man.cgi?query=ng_ipfw&amp;manpath=FreeBSD+6.0-current">
      ng_ipfw(4)</url>

      <url href="http://people.freebsd.org/~glebius/totest/ng_nat/">
      ng_nat work in progress</url>
    </links>

    <body>
      <p>This report covers period since August 2004 until April
      2005.</p>

      <p>New nodes. Two new nodes have been added to base FreeBSD
      distribution. ng_netflow(4) node, which implements NetFlow version
      5 accounting of IPv4 packets. ng_ipfw(4) node, which diverts
      packets from ipfw(4) to netgraph(4) and back. A well known
      ng_ipacct node has been added to ports tree.</p>

      <p>SMP. Nodes, which need to allocate unique names have been
      protected with mutex in RELENG_5, and subr_unit allocator in HEAD.
      Nodes, which need to run periodical jobs were reworked to use
      mpsafe ng_callout() API. ng_tty(4) node has been overhauled to be
      compatible with debug.mpsafenet=1. NetGraph ISR and callout are now
      declared MPSAFE in HEAD.</p>

      <p>NetGraph flow control. Two nodes ng_ether(4) and ng_cisco(4)
      have been improved to emit flow control messages to upstream node,
      when state of link changes. New link failure detection method have
      been introduced in ng_one2many(4) node - listening to these flow
      control messages from downstream.</p>
    </body>

    <help>
      <task>more SMP testing of many nodes</task>

      <task>review locking of graph restructuring</task>

      <task>ng_nat node - an in-kernel natd(8)</task>

      <task>make ng_bridge(4) multithreaded</task>
    </help>
  </project>

  <project cat='kern'>
    <title>drm</title>

    <contact>
      <person>
        <name>
          <given>Eric</given>

          <common>Anholt</common>
        </name>

        <email>anholt@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://r300.sourceforge.net/">ATI R300 DRI project</url>
    </links>

    <body>
      <p>A DRM update was finally committed to -current on 2005-04-15,
      after jhb@ did the necessary fix to vm_mmap. New development
      drivers were added for mach64 and r300 (see URL for info). The
      nearly-finished code for savage and i915 were also added, but left
      disconnected from the build. However, the most visible change is
      likely the support for texture tiling, color tiling, and HyperZ on
      Radeons, which (with updated userland) likely provide a 50-75%
      framerate increase in many applications.</p>
    </body>

    <help>
      <task>Find someone with newbus knowledge to figure out why the i915
      won't attach to drmsub0.</task>

      <task>Finish porting the savage driver.</task>

      <task>Integrate busdma code from Tonnerre (NetBSD).</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Storage driver SMPng locking</title>

    <contact>
      <person>
        <name>
          <given>Scott</given>

          <common>Long</common>
        </name>

        <email>scottl@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>Several storage drivers have been taken out from under the Giant
      mutex in the past few months. Thanks to sponsorship from 
      <a href="http://www.freebsdsystems.com">FreeBSD Systems, Inc</a>

      and 
      <a href="http://www.imp.ch">ImproWare, AG, Switzerland</a>

      , the LSI MegaRAID (AMR) and IBM/Adaptec ServeRAID (IPS) drivers
      have been locked. SMPng locking is a key step in improving the
      performance of system drivers in FreeBSD 5.x and beyond, and both
      of these drivers are showing the benefits of this. FreeBSD 5.4 will
      contains these improvements when it is released.</p>

      <p>Similar work is ongoing with the 3WARE Escalade (TWE) driver,
      and preliminary patches have been made available to testers. I hope
      to have this driver complete in time for the next FreeBSD
      release.</p>

      <p>Unfortunately, most benefits can only be gained from pure block
      storage drivers such as the ones mentioned here due to the SCSI
      subsystem in FreeBSD (CAM) not be locked itself at this time. It is
      possible, however, to lock a CAM sub-driver and bring the driver's
      interrupt handler out from under Giant for a partial gain. The Sun
      FAS366 SCSI driver (ESP) operates like this. Volunteers to lock
      other drivers or to tackle locking CAM are gladly accepted, so
      please contact me if you are interested.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Filesystem journalling for UFS</title>

    <contact>
      <person>
        <name>
          <given>Scott</given>

          <common>Long</common>
        </name>

        <email>scottl@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://repoman.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/scottl/ufsj" />
    </links>

    <body>
      <p>It's time to bite the bullet and admit that fsck is no longer
      scalable for modern storage capacities. While a healthy debate can
      still be had on the merits and data integrity guarantees of
      journalling vs. SoftUpdates, the fact that SoftUpdates still
      requires a fsck to ensure consistency of the filesystem metadata
      after an unclean shutdown means uptime is lost. While background
      fsck is available, it saps system performance and stretched the
      fsck time out to hours.</p>

      <p>Journalling provides a way to record transactions that might not
      have fully been written to disk before the system crashed, and then
      quickly recover the system back to a consistent state by replaying
      these transactions. It doesn't guarantee that no data will be lost,
      but it does guarantee that the filesystem will be back to a
      consistent state after the replay is performed. This contrasts to
      SoftUpdates that re-arranges metadata updates so that
      inconsistencies are minimized and easy to recover from, though
      recovery still requires the traditional full filesystem scan.</p>

      <p>Journalling is a key feature of many modern filesystems like
      NTFS, XFS, JFS, ReiserFS, and Ext3, so the ground is well covered
      and the risks for UFS/FFS are low. I'm aware that groups from CMU
      and RPI have attempted similar work in the past, but unfortunately
      the work is either very outdates, or I haven't had any luck in
      contacting the groups. Is this absence, I've decided to work on
      this project myself in hopes of having a functional prototype in
      time for FreeBSD 6.0.</p>

      <p>The approach is simple and journals full metadata blocks instead
      of just deltas or high-level operations. This greatly simplifies
      the replay code at the cost of requiring more disk space for the
      journal and more work within the filesystem to identify discreet
      update points. An important design consideration is whether to make
      the journal data and code compatible with the UFS2 filesystem, or
      to start a new UFS3 derivative. Since the latter presents a very
      high barrier to adoption for most people, I'm going to try to make
      it a compatible option for UFS2. This means that the journal blocks
      will likely appear as an unlinked file to legacy filesystem and
      fsck code, and will be treated as such. This will allow seamless
      fallback to using fsck, though once the unlinked journal data
      blocks are reclaimed by fsck, the user will have to take action to
      re-create the journal file again.</p>

      <p>One key piece of journalling is ensuring that each journal
      transaction is fully written to disk before the associated metadata
      blocks are written to the filesystem. I plan to adopt the buffer
      'pinning' mechanism from Alexander Kabaev's XFS work to assist with
      this. This will allow the journalling subsystem fine-grained
      control over which blocks get flushed to disk by the buffer daemon
      without having to further complicate the UFS/FFS code. One
      consideration is how Softupdates falls into this and whether it is
      mutually exclusive of journalling or if it can help provide
      transaction ordering functionality to the journal. Research here is
      on-going.</p>

      <p>Some preliminary work can be found in Perforce in the
      //depot/user/scottl/ufsj/... tree or at the URL provided. Hopefully
      this will quickly accelerate.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Status Report for FreeBSD ATA driver project</title>

    <contact>
      <person>
        <name>
          <given>S&#248;ren</given>

          <common>Schmidt</common>
        </name>

        <email>sos@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>ATA mkIII has been committed to -current after a couple of month
      testing as patches post on -current and 5-stable. I will continue
      to provide patches for 5-stable for those that need up-to-date ATA
      support there.</p>

      <p>Here a short rehash of what mkIII brings:</p>

      <p>ATA is now fully modular so each part can be loaded/unloaded at
      will to provided the wanted functionality.</p>

      <p>Much improved SATA support that support hotplug events on
      controllers that support it (Promise, SiS, nVidia so far) ie the
      system will automagically detect when SATA devices come and go and
      add/delete device entries etc.</p>

      <p>Much improved ATA RAID support. The ata-raid driver has been
      largely rewritten to take advantage of the features the improved
      infrastructure provides, including composite ATA operations etc.
      The rebuild functionality has been changed to rebuild on userland
      reads, so a simple dd of the entire array will get it rebuild (what
      atacontrol now does). This means that the resources used for this
      can be better tailored to the actually usage pattern if needed. ATA
      RAID now supports 10+ different RAID metadata formats, so most BIOS
      defined ATA RAID arrays can be picked up and used. The number of
      metadata formats that can be created from within FreeBSD is still
      limited though and is not a high priority feature right now.</p>

      <p>The lowlevel infrastructure of the ATA driver has been refined
      even further to support "strange" chipsets much more easily and in
      most case transparent to the higher levels. This to easy ports to
      new platforms where ATA controllers doesn't necessarily have the
      x86 legacy layout.</p>

      <p>Lots of bug fixes and corrections all over the driver proper.
      The rework of the infrastructure has revealed bugs and deficiencies
      that has been fixed in the process of modulerising ATA and making
      the infrastructure more generic, and hopefully easier to
      understand.</p>

      <p>The work continues to keep ATA on top of new chipsets and other
      advancements in the ATA camp. SATA ATAPI support is in the works
      and so are support for NCA/TCQ (tags). Donations of unsupported
      hardware is the way to get it supported as I'm way out of my budget
      for new hardware for the next decade or so according to my wife
      :)</p>
    </body>

    <help>
      <task>Lots of testing wanted, especially SATA and RAID
      support</task>
    </help>
  </project>

  <project cat='proj'>
    <title>GSHSEC - GEOM class for handling shared secret</title>

    <contact>
      <person>
        <name>
          <given>Pawel Jakub</given>

          <common>Dawidek</common>
        </name>

        <email>pjd@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://www.freebsd.org/cgi/man.cgi?query=gshsec&amp;apropos=0&amp;sektion=0&amp;manpath=FreeBSD+6.0-current&amp;format=html">
      Manual page.</url>
    </links>

    <body>
      <p>GSHSEC is a GEOM class used for handling shared secret data
      between multiple GEOM providers. For every write request, SHSEC
      class splits the data using XOR operation with random data, so N-1
      providers gets just random data and one provider gets the data
      XORed with the random data from the other providers. All of the
      configured providers must be present in order to reveal the secret.
      The class is already committed to HEAD and RELENG_5 branches.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>ATAPI/CAM</title>

    <contact>
      <person>
        <name>
          <given>Thomas</given>

          <common>Quinot</common>
        </name>

        <email>thomas@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>ATAPI/CAM integration with the new ATA (mkIII) framework is now
      completed. ATAPI/CAM is now available as a loadable module
      (atapicam.ko). It is also independent from the native ATAPI drivers
      again, as was the case before mkIII.</p>

      <p>Thanks to Scott Long and S&#248;ren Schmidt for their
      participation in the integration work.</p>
    </body>
  </project>

  <project cat='vendor'>
    <title>twa driver</title>

    <contact>
      <person>
        <name>
          <given>Vinod</given>

          <common>Kashyap</common>
        </name>

        <email>vkashyap at amcc.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twa/">
      source code</url>

      <url
      href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/twa/">
      source code</url>
    </links>

    <body>
      <p>A newly re-architected twa(4) driver was committed to 6 -CURRENT
      on 04/12/2005. Highlights of this release are:</p>

      <ol>
        <li>The driver has been re-architected to use a "Common Layer"
        (all tw_cl* files), which is a consolidation of all
        OS-independent parts of the driver. The FreeBSD OS specific
        portions of the driver go into an "OS Layer" (all tw_osl* files).
        This re-architecture is to achieve better maintainability,
        consistency of behavior across OS's, and better portability to
        new OS's (drivers for new OS's can be written by just adding an
        OS Layer that's specific to the OS, by complying to a "Common
        Layer Programming Interface (CLPI)" API. If there's interest in
        porting the 3ware driver to any other OS, you may contact ctchu
        at amcc.com to get a copy of the CLPI specifications.</li>

        <li>The driver takes advantage of multiple processors. It does
        not need to be Giant protected anymore.</li>

        <li>The driver has a new firmware image bundled, the new features
        of which include Online Capacity Expansion and multi-lun support,
        among others. More details about 3ware's 9.2 release can be found
        here: 
        <a
        href="http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf">
        http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf</a>
        </li>
      </ol>
    </body>
  </project>

  <project cat='net'>
    <title>IPv6 Support for IPFW</title>

    <contact>
      <person>
        <name>
          <given>Brooks</given>

          <common>Davis</common>
        </name>

        <email>brooks@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://lists.freebsd.org/pipermail/cvs-all/2005-April/116671.html" />
    </links>

    <body>
      <p>In April 18th, I committed support for IPv6 to IPFW. This
      support was written by two student of Luigi's, Mariano Tortoriello
      and Raffaele De Lorenzo. I updated it to use PFIL_HOOKS and fixed a
      few minor issues. As of this commit, IP6FW should be considered
      deprecated in favor of IPFW. It should be possible to MFC this
      change to 5.x, but that is not currently planned.</p>
    </body>

    <help>
      <task>Testing.</task>

      <task>IP6FW to IPFW migration guide.</task>

      <task>Patches relative to 5-STABLE.</task>
    </help>
  </project>

  <project cat='net'>
    <title>Removable interface improvements.</title>

    <contact>
      <person>
        <name>
          <given>Brooks</given>

          <common>Davis</common>
        </name>

        <email>brooks@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/" />

      <url href="http://www.freebsd.org/projects/dingo/" />
    </links>

    <body>
      <p>This project is an attempt to clean up handling of network
      interfaces in order to allow interfaces to be removed reliably.
      Current problems include panics if Dummynet is delaying packets to
      an interface when it is removed.</p>

      <p>I am currently working to remove struct ifnet's from device
      driver structures to allow them to be managed properly upon device
      removal. I believe I have removed all known instances of casting a
      struct ifnet pointer to something else (except that that are just
      magic values and not real struct ifnets.) I will begin committing
      these changes to the tree shortly and will then add a new function
      if_alloc() that will allocate struct ifnets. if_detach() will be
      modified to destroy them.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>cpufreq</title>

    <contact>
      <person>
        <name>
          <given>Nate</given>

          <common>Lawson</common>
        </name>

        <email>njl</email>
      </person>
    </contact>

    <links>
      <url
      href="http://www.freebsd.org/cgi/man.cgi?query=cpufreq&amp;manpath=FreeBSD+6.0-current&amp;format=html">
      cpufreq man page</url>
    </links>

    <body>
      <p>The cpufreq project was committed to 6-CURRENT in early February
      and has undergone bugfixes and updates. It will soon be MFCd to
      5-STABLE.</p>

      <p>The cpufreq driver provides a unified kernel and user interface
      to CPU frequency control drivers. It combines multiple drivers
      offering different settings into a single interface of all possible
      levels. Users can access this interface directly via sysctl(8), by
      indicating to power_profile that it should switch settings when the
      AC line state changes, or by using powerd(8).</p>

      <p>For example, an absolute driver offering frequencies of 1000 Mhz
      and 750 Mhz combined with a relative driver offering settings of
      100% and 50% would result in cpufreq providing levels of 1000, 750,
      500, and 375 Mhz.</p>

      <p>Colin Percival helped with powerd(8), which provides automatic
      control of CPU frequencies. The adaptive mode is especially
      interesting since it attempts to respond to changes in system load
      while reducing power consumption.</p>

      <p>Current hardware drivers include acpi_perf (ACPI CPU performance
      states), est (Intel Enhanced SpeedStep for Pentium-M), ichss
      (Intel's original SpeedStep for ICH), and powernow (AMD Powernow!
      K7 and K8 support). Other drivers for relative hardware include
      acpi_throttle (ACPI CPU throttling) and p4tcc (Pentium 4 Thermal
      Control Circuitry)</p>

      <p>Thanks to Bruno Ducrot for the powernow driver, Colin Percival
      for the est driver, and the many testers who have sent in
      feedback.</p>
    </body>

    <help>
      <task>We'd appreciate someone with a Transmeta CPU converting the
      existing longrun driver to the cpufreq framework. It would also be
      good if someone wrote a VIA Longhaul driver. See the Linux
      arch/i386/kernel/cpu/cpufreq directory for examples.</task>

      <task>Various other architectures, including ARM, have CPU power
      control that could be implemented as a cpufreq driver.</task>

      <task>The powerd(8) algorithm is rather simple and we'd appreciate
      more help in testing it and alternative algorithms with various
      workloads. The -v flag causes powerd to report frequency
      transitions and print a summary of total energy used upon
      termination. This should help testers profile their
      algorithms.</task>
    </help>
  </project>

  <project cat='net'>
    <title>Move ARP out of routing table</title>

    <contact>
      <person>
        <name>
          <given>Qing</given>

          <common>Li</common>
        </name>

        <email>qingli@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.freebsd.org/~qingli/">containing the
      patch</url>
    </links>

    <body>
      <p>I have finished the basic functionality for both IPv4 and IPv6.
      The userland utilities ("arp" and "ndp") have been updated. I have
      tested the changes with "make buildworld". I have been testing the
      new code in a production environment and things appear to be
      stable. Gleb Smirnoff (glebius@FreeBSD.org) has provided review
      comments and I have incorporated these feedback into the patch. I
      have discussed the IPv6 changes with two of the core KAME
      developers during the last IETF meeting in March 2005. They
      indicated that these changes may result in divergence from the KAME
      project but that is not necessarily a bad thing.</p>
    </body>

    <help>
      <task>I am waiting for review feedback from my mentor Andre. I need
      locking experts to help me fix my giant-lock shortcut. I am hoping
      to send out the code for wider review soon.</task>
    </help>
  </project>

  <project cat='net'>
    <title>Support for telephone hardware (aka Zaptel)</title>

    <contact>
      <person>
        <name>
          <given>Maxim</given>

          <common>Sobolev</common>
        </name>

        <email>sobomax@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Oleksandr</given>

          <common>Tymoshenko</common>
        </name>

        <email>gonzo@pbxpress.com</email>
      </person>

      <person>
        <name>
          <given>Max</given>

          <common>Khon</common>
        </name>

        <email>fjoe@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://www.digium.com/index.php?menu=hardware_products" />
    </links>

    <body>
      <p>During the last 2 months lot of progress has been made. Existing
      support for TDM400 (FXO/FXS) has been significantly improved.
      Drivers for PRI and BRI cards have been added and now should be
      considered beta-quality.</p>
    </body>

    <help>
      <task>More testing of PRI/BRI drivers.</task>

      <task>Add support for channelized DS3 card(s).</task>
    </help>
  </project>

  <project cat='ports'>
    <title>FreshPorts</title>

    <contact>
      <person>
        <name>
          <given>Dan</given>

          <common>Langille</common>
        </name>

        <email>dan@langille.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freshports.org/">FreshPorts</url>
    </links>

    <body>
      <p>This is the first status report for FreshPorts. FreshPorts
      started in early 2000 and now contains over 170,000 commits.
      FreshPorts is primarily concerned with port commits, but actually
      processes and records all commits to the FreeBSD source tree. Its
      sister site, 
      <a href="http://www.freshsource.org/">FreshSource</a>

      uses the same database as FreshPorts but has a wider reporting
      scope. In recent months, FreshPorts has been enhanced to process
      and include 
      <a href="http://www.vuxml.org/freebsd/">VuXML</a>

      information. In addition, RESTRICTED and NO_CDROM have been added
      to list of things that FreshPorts keeps track of. For unmaintained
      ports, we recently added this message: 
      <p>
        <em>There is no maintainer for this port. 
        <br />

        Any concerns regarding this port should be directed to the
        FreeBSD Ports mailing list via ports@FreeBSD.org</em>
      </p>

      FreshPorts, with direct and indirect support from the FreeBSD
      community, continues to evolve and to provide a great tool for
      users and developers alike.</p>
    </body>

    <help>
      <task>Provide a copy/paste method for updating watch lists</task>

      <task>improvement of query times for "People watching this port,
      also watch"</task>

      <task>pagination of commits within a port</task>

      <task>pagination of watch lists</task>

      <task>create an RSS feed for individual watch lists</task>
    </help>
  </project>

  <project cat='misc'>
    <title>BSDCan</title>

    <contact>
      <person>
        <name>
          <given>Dan</given>

          <common>Langille</common>
        </name>

        <email>dan@langille.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.bsdcan.org/" />
    </links>

    <body>
      <p>BSDCan made a strong debut in 
      <a href="http://www.bsdcan.org/2004/">2004</a>

      . The favorable reception gave us a strong incentive for 
      <a href="http://www.bsdcan.org/2005/">2005</a>

      . We have been rewarded with a very interesting 
      <a href="http://www.bsdcan.org/2005/schedule.php">program</a>

      and a higher rate of registrations. Percentage-wise, we have more
      Europeans than last year as they have decided that the trip across
      the Atlantic is worth taking. We know they won't be disappointed.
      See you at BSDCan 2005!</p>
    </body>

    <help>
      <task>volunteers needed for the conference</task>
    </help>
  </project>

  <project cat='ports'>
    <title>Ports Collection</title>

    <contact>
      <person>
        <name>
          <given>Mark</given>

          <common>Linimon</common>
        </name>

        <email>linimon@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/ports/">The FreeBSD ports
      collection</url>

      <url href="http://portsmon.firepipe.net/index.html">FreeBSD ports
      monitoring system</url>

      <url href="http://www.freebsd.org/portmgr/index.html">The FreeBSD
      Ports Management Team</url>
    </links>

    <body>
      <p>As this report was being written, the 5.4 release was
      ongoing.</p>

      <p>A new charter for the Ports Management (portmgr) team was
      approved by core and has been posted at the URL above. In addition,
      two other new pages describe the policies of the team, and the
      range of QA activities both during and between releases.</p>

      <p>Due to being absent from email discussions for some time, Oliver
      Eikemeier (eik) was moved to non-voting status on portmgr.</p>

      <p>We have added several new and very active committers recently;
      this is helping us to keep the PR count low even with the large
      numbers of new ports that have been added.</p>

      <p>Several more iterations of infrastructure changes have been
      tested on the cluster and committed; see /usr/ports/CHANGES for
      details.</p>

      <p>Updates have occurred to x.org, GNOME, KDE, and perl.</p>

      <p>There have been some updates to the Porter's Handbook, but more
      sections are still in need of updates to include recent changes in
      practices.</p>

      <p>The ports collection now contains almost 12,750 ports.</p>
    </body>

    <help>
      <task>Further progress has been made in cracking down on ports that
      install files outside the approved directories and/or do not
      deinstall cleanly (see "Extra files not listed in PLIST" on 
      <a href="http://pointyhat.freebsd.org/errorlogs/">pointyhat</a>

      ) and this will remain a focus area. We appreciate everyone who has
      sent in PRs or committed fixes.</task>

      <task>Demand for new features and revisions for bsd.port.mk is
      still very high and the portmgr team is trying to work through them
      all.</task>

      <task>We still have a large number of PRs that have been assigned
      to committers for some time (in fact, they constitute the
      majority). One goal of portmgr in the coming months is to try to
      reduce this number, and we would like to ask our committers to help
      us out as much as possible.</task>
    </help>
  </project>

  <project cat='arch'>
    <title>PowerPC Port</title>

    <contact>
      <person>
        <name>
          <given>Peter</given>

          <common>Grehan</common>
        </name>

        <email>grehan@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Progress continues. X.Org 6.8.1 server has been up and running
      on a number of different Macs, and the work is being merged into
      6.8.2. There have been successful installs on Mac Minis</p>
    </body>
  </project>

  <project cat='vendor'>
    <title>OpenBSD packet filter - pf</title>

    <contact>
      <person>
        <name>
          <given>Max</given>

          <common>Laier</common>
        </name>

        <email>mlaier@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://pf4freebsd.love2party.net/">pf4FreeBSD
      Homepage</url>

      <url href="http://people.freebsd.org/~mlaier/pf37/">pf 3.7 patches</url>
    </links>

    <body>
      <p>OpenBSD is about to release 
      <a href="http://www.openbsd.org/37.html">version 3.7</a>

      . There are 
      <a href="http://people.freebsd.org/~mlaier/pf37/">patches</a>

      available to catch up with the development done in OpenBSD 3.6 and
      3.7. These patches are in an early stage, but ready for testing,
      please help.</p>

      <p>Otherwise there was not much activity on pf, as it already is
      quite stable. Other work, such as CARP and if_bridge are having
      impact on pf in FreeBSD however, please see the respective
      reports.</p>
    </body>

    <help>
      <task>Alpha/Betatesting of the 3.7 import</task>

      <task>Testing with if_bridge</task>
    </help>
  </project>

  <project cat='bin'>
    <title>libthread</title>

    <contact>
      <person>
        <name>
          <given>David</given>

          <common>Xu</common>
        </name>

        <email>davidxu@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>libthread is a pure 1:1 threading library, it had stayed in my
      perforce branch for a long time, recent it was imported into source
      tree and replaced libthr. The purpose of the work is to improve 1:1
      threading on FreeBSD, the library is designed in mind that simplest
      is best, currently it can run almost all of the applications
      libpthread can run, but gives you better SMP performance. The
      library size is smaller than libpthread.</p>

      <p>Currently it supports i386, AMD64, sparc64 and ia64 and may
      support alpha, powerpc and arm. I didn't do many tests on sparc64
      and ia64, I only tested it on FreeBSD cluster machines. For i386, I
      always used LDT, but know that Peter committed GDT code, and now
      there is no 8191 threads limitation anymore.</p>

      <p>libthread_db was updated to support debugging the new libthr. It
      is an assistant library used by gdb to debug threaded process, that
      understands internal detail of thread libraries. I have improved it
      a bit to support event reports for libthr, currently it can report
      thread creation and death events. That means a thread that was
      created and died will be reported to the user regardless if you are
      tracking it or not.</p>
    </body>

    <help>
      <task>I am working on thread creation performance, currently it
      needs considerable number of libc functions and syscalls to create
      a thread, I would like to introduce a syscall to create a thread in
      atomically. That means one syscall will setup thread entry, tls, and
      signal mask and PTHREAD_SCOPE_PROCESS/SYSTEM; in future maybe even
      CPU affinity masks, when userland entry code is executed, the
      thread is already fully setup.</task>

      <task>Process shareable synchronization objects. In Current FreeBSD
      does not support this specification. The idea about the shareable
      mutex and others is like other systems did, one can use mmap() to
      create a shared memory page, and put a pthread synchronization
      object in the page, multiple processes use the shared object to
      control resource access. I am not working on it, if someone is
      interested, please let me know.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Coverity Code Analysis</title>

    <contact>
      <person>
        <name>
          <given>Sam</given>

          <common>Leffler</common>
        </name>

        <email>sam@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.coverity.com/" />
    </links>

    <body>
      <p>There has been an ongoing effort to review the kernel source
      code using Coverity's source code analysis tools
      (http://www.coverity.com). These tools check for a variety of
      problems such as null pointer dereference, use-after-free of
      allocated variables, invalid array references, etc. This work is a
      joint project between FreeBSD and Coverity.</p>

      <p>Two passes have been completed over the 6-current kernel source
      code base and all significant problems have been corrected. These
      runs were done in February and March of this year. A few reports of
      minor problems await response from outside groups and will be
      resolved in time for the first 6.x release. Another analysis run
      over the kernel will happen soon. We are looking for a way to use
      these tools on a regular basis as they have been helpful in
      improving the code base.</p>

      <p>Thanks to Coverity for their help and especially Ted Unangst.
      Several developers have been especially helpful in resolving
      reports: Poul-Henning Kamp, David Schultz, Pawel Jakub Dawidek,
      George V. Neville-Neil, and Matthew Dodd.</p>
    </body>
  </project>

  <project cat='net'>
    <title>Wireless Networking Support</title>

    <contact>
      <person>
        <name>
          <given>Sam</given>

          <common>Leffler</common>
        </name>

        <email>sam@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>Several new drivers by by Damien Bergamini were brought into the
      tree: iwi, ipw, ral, and ural.</p>

      <p>WPA-PSK support for the ndis driver was contributed by Arvind
      Srinivasa.</p>

      <p>A new tx rate control algorithm for the ath driver was
      contributed by John Bicket. It will become the default algorithm
      shortly.</p>

      <p>Work on multi-bss support is going on outside the cvs tree. A
      presentation on this work will be given at BSDCan 2005 and the
      slides for the talk will be made available after.</p>
    </body>

    <help>
      <task>Drivers other than ath and ndis need updates to support the
      new security protocols.</task>

      <task>hostapd needs work to support the IAPP and 802.11i
      preauthentication protocols (these are simple conversions of
      existing Linux code).</task>

      <task>The OpenBSD dhclient program has been ported but needs a
      developer that will maintain it once it is brought into cvs.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Many subdirs for UFS</title>

    <contact>
      <person>
        <name>
          <given>David</given>

          <common>Malone</common>
        </name>

        <email>dwmalone@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://groups-beta.google.com/group/muc.lists.freebsd.fs/browse_frm/thread/a36d1143d695287e/40cad00cf2c0823b?hl=en#40cad00cf2c0823b">
      Thread on freebsd-fs</url>
    </links>

    <body>
      <p>I'm currently looking at the limit on the number of
      subdirectories a directory can have in UFS. There is currently a
      limit of 32K subdirectories because of the 16 bit link count field
      in both struct stat and the on-disk inode format. The thread above
      shows that dirhash provides acceptable performance for directories
      with 100k subdirectories using a prototype patch. Two options for
      allowing many subdirectories seem to exist: changing the link
      counting scheme for directories and expanding the link count field.
      The prototype patch implements the first scheme and there are plans
      to investigate the second scheme (which may require an ABI
      change).</p>
    </body>
  </project>

  <project cat='misc'>
    <title>IMUNES - a FreeBSD based kernel-level network topology
    emulator</title>

    <contact>
      <person>
        <name>
          <given>Miljenko</given>

          <common>Mikuc</common>
        </name>

        <email>miljenko@tel.fer.hr</email>
      </person>

      <person>
        <name>
          <given>Marko</given>

          <common>Zec</common>
        </name>

        <email>zec@tel.fer.hr</email>
      </person>
    </contact>

    <links>
      <url href="http://www.imunes.net/" />
    </links>

    <body>
      <p>IMUNES is a scalable kernel-level network topology emulator
      based on FreeBSD. In IMUNES each virtual node operates on its
      private instance of network stack state variables, such as routing
      tables, interface addresses, sockets, ipfw rules etc. Most if not
      all existing FreeBSD application binaries, including routing
      protocol daemons such as quagga or XORP, can run unmodified within
      the context of virtual nodes with no noticeable performance
      penalty. Complex network topologies can be constructed by
      connecting the virtual nodes through netgraph-based link-layer
      paths. A GUI tool allows for simple and intuitive network topology
      specification, deployment and management. The current version of
      IMUNES is based on FreeBSD 4.11-RELEASE and supports IPv4.</p>
    </body>
  </project>

  <project cat='arch'>
    <title>XenFreeBSD - FreeBSD on Xen</title>

    <contact>
      <person>
        <name>
          <given>Kip</given>

          <common>Macy</common>
        </name>

        <email>kmacy@fsmware.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/">Xen
      project page</url>

      <url href="http://xen.bkbits.net/">Xen changeset logs</url>
    </links>

    <body>
      <p>FreeBSD 5.3 runs on the stable and the development branches of
      xen and is now checked into both trees. Over the next couple of
      weeks I will be adding improvements for better batching of page
      table updates and SMP support.</p>
    </body>

    <help>
      <task>FreeBSD support for running as Domain 0, i.e. running as the
      hosting operating system.</task>

      <task>FreeBSD support for VM checkpoint and migration.</task>
    </help>
  </project>

  <project cat='net'>
    <title>Dingo</title>

    <contact>
      <person>
        <name>
          <given>George</given>

          <common>Neville-Neil</common>
        </name>

        <email>gnn@neville-neil.com</email>
      </person>
    </contact>

    <links>
      <url href="http://people.freebsd.org/~gnn/Dingo/notebook/60.html">
      Project page (out of date)</url>

      <url href="http://zoo.unixdaemons.com/index.php?blog=7">Blog
      covering test framework</url>
    </links>

    <body>
      <p>On the protocol conformance tool I have finally made some
      progress getting a scriptable packet library using libnet, and
      SWIG. This will hopefully become a port that can then be used to do
      conformance testing on protocol stack changes. Qing Li has
      separately taken up the ARP rewrite and that will be taken out of
      the Dingo project pages.</p>
    </body>

    <help>
      <task>Many :-)</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Interrupt Latency</title>

    <contact>
      <person>
        <name>
          <given>Warner</given>

          <common>Losh</common>
        </name>

        <email>imp@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>I've setup a test system to measure interrupt latency on FreeBSD
      5.3 and current. So far I've measured the baseline latency for a
      300MHz embedded cyrix based single board computer. I've tried a
      number of different strategies to optimize the interrupt path. Most
      of these strategies resulted in some improvement of the time it
      takes to get from the start of the interrupt servicing to the
      driver's ISR. These improvements turned out to be about 1-2% of the
      processing times on this single board computer, but a wash on
      faster machines. However, the time between when the interrupt
      should happen, and when FreeBSD starts to service the interrupt is
      the dominant factor in these measurements. Despite the fact that
      these are fast interrupt handlers (so the scheduler is out of the
      loop), I routinely see average latencies of 18us, with large
      variations (on the order of 5us standard deviation).</p>
    </body>

    <help>
      <task>I need to measure the latencies with 4.x and current to
      characterize the differences more precisely. I'm especially
      interested in the effects on interrupt latency that the elimination
      of mixed mode will cause.</task>

      <task>I need to characterize different parts of our ISR routines to
      see if some of the variation I've seen so far can be reduced by
      improved coding techniques.</task>

      <task>I need to re-run my tests with 5.4 and summarize my results
      in a paper.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Infrastructure Cleanup</title>

    <contact>
      <person>
        <name>
          <given>Warner</given>

          <common>Losh</common>
        </name>

        <email>imp@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Takahashi</given>

          <common>Yoshihiro</common>
        </name>

        <email>nyan@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>Unglamorous cleanup of the code base continues. The focus of
      recent efforts have been to reduce the number of machine #ifdefs
      that are in the machine independent code. In addition, we're also
      trying to increase code sharing between pc98 and i386 ports and
      reduce the number of #ifdef PC98 instances in the tree.</p>

      <p>In addition, a number of cleanup tasks are underway for
      different parts of the kernel that are more complicated than
      necessary. Recently, the pccard code's allocation routines were
      simplified to reassign ownership of resources more directly than
      before. The search is on for other areas that can benefit from
      cleanup.</p>
    </body>

    <help>
      <task>On pc98, there's no such thing as an ISA bus. It is desirable
      to move to having cbus appear in the probe messages. This would
      also allow for additional segregation of pc98 specific code in the
      drivers and eliminate many ifdefs. Ideally, isa and cbus would
      share a common newbus ancestor class so their similarities can be
      exploited (they both have PNPBIOS enumeration methods, for
      example).</task>

      <task>cbus devices can have complicated resources. There's support
      for vectors of resources. Yet there's no support for populating a
      vector of resources from the plug and play information. Doing so
      would help the complex world of pc98 a lot, and the odd edge cases
      in i386 (floppy, ata) a little.</task>

      <task>The hints mechanism provides a way to associate hardware with
      drivers and resource that would otherwise be completely unknown to
      the system. A refinement in the hints mechanism to allow matching
      of driver instances to resources is desirable. This would allow one
      to hardwire sio0 to 0x2f8, even when the serial device in the plug
      and play resource list (or acpi resource list) is listed second. A
      further refinement could also be wiring sio0 to "port B" as defined
      by acpi or some other enumeration method. Chances are good that
      these seemingly related concepts may need separate implementations
      due to the decision points for unit assignment.</task>

      <task>Pccard, cardbus and usb probe their devices after interrupts
      are enabled. It would be desirable to hook into new kernel APIs to
      allow the mounting of root to be put off until those systems know
      that they are done with their initial probe of the devices present
      at boot.</task>
    </help>
  </project>

  <project cat='misc'>
    <title>FreeBSD Security Officer and Security Team</title>

    <contact>
      <person>
        <name>
          <given>Security</given>

          <common>Officer</common>
        </name>

        <email>security-officer@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Security</given>

          <common>Team</common>
        </name>

        <email>security-team@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/security/" />

      <url
      href="http://www.freebsd.org/administration.html#t-secteam" />

      <url href="http://vuxml.freebsd.org/" />
    </links>

    <body>
      <p>In January 2005, Warner Losh (Security Officer Emeritus) stepped
      down from the FreeBSD Security Team in order to better devote his
      time to other projects. In March, Colin Percival was named as a
      second Deputy Security Officer, joining Dag-Erling Sm&#248;rgrav in
      that position. The current Security Team membership is published on
      the web site.</p>

      <p>So far in 2005, four security advisories have been issued
      concerning problems in the base system of FreeBSD, three of which
      were specific to FreeBSD. The Vulnerabilities and Exposures Markup
      Language (VuXML) document has continued to be updated by the
      Security Team and the Ports Committers documenting new
      vulnerabilities in the FreeBSD Ports Collection. As of April 17,
      127 entries have been added in 2005 bringing the FreeBSD VuXML file
      up to a total of 422 entries.</p>

      <p>In the past months both the 
      <a href="http://vuxml.FreeBSD.org/">VuXML web site</a>

      and the 
      <a href="http://www.FreshPorts.org/">FreshPorts</a>

      VuXML integration have been improved. The VuXML web site has had a
      face lift and, among other things, each package now has a separate
      web page which lists all documented vulnerabilities for the
      particular package. 
      <a href="http://cve.mitre.org/">CVE</a>

      information is now also included directly on the VuXML web
      site.</p>

      <p>Finally, the first few months of 2005 also saw FreeBSD 4.8 --
      the first release to be offered "extended support" -- reach its
      designated End of Life. The currently supported releases are
      FreeBSD 4.10, 4.11, and 5.3.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>FreeBSD Release Engineering</title>

    <contact>
      <person>
        <name>
          <given>RE</given>
          <common>Team</common>
        </name>
        <email>re@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/releng" />
    </links>

    <body>
      <p>FreeBSD 4.11, the final formal release of the 4.x series, was
      released on 25 Jan 2005.  Many thanks to the all of the developers
      and users over the past 5 years who made it successful.  While no
      more releases are planned, the security team will continue to
      support it through security update patches until 2007.  Developers
      are also free to commit bug fixes and low-risk features to the
      RELENG_4 branch for the foreseeable future.</p>
      <p>FreeBSD 5.4 is going through its final release candidate stages
      and is expected to be released in late April.  Its focus is mostly
      bug fixes and minor feature and performance improvements, so it is
      an excellent target for those looking to upgrade from previous
      versions or to give FreeBSD a try for the first time.  FreeBSD 5.5
      will be release in about 4-6 months after 5.4.</p>
      <p>FreeBSD 6.0 is rapidly approaching also.  In contrast to FreeBSD
      5.0, the goal is to take a more incremental approach to major
      changes, and not wait for years to get as many features in as
      possible.  FreeBSD 6.0 will largely be an evolutionary change from
      the 5.x series, with the largest changes centered around
      multi-threading and streamlining the filesystem and device layers.
      Feature freeze and code freeze for 6.0 are coming up in May and
      June, and we hope to have 6.0 stable and ready for release in July
      or August.</p>
      <p>The release engineering team has also started doing monthly
      informal snapshots of the 6-CURRENT and 5-STABLE trees.  These are
      intended to increase the exposure of new features and get more
      users involved in testing and providing feedback.  Snapshots can
      be found at <a href="http://www.freebsd.org/snapshots">
      http://www.freebsd.org/snapshots</a>.</p>
    </body>
  </project>

  <project cat='net'>
    <title>New Wireless Drivers</title>

    <contact>
      <person>
        <name>
          <given>Damien</given>

          <common>Bergamini</common>
        </name>

        <email>damien@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://ipw2100.sourceforge.net/firmware.php?fid=4" />

      <url href="http://ralink.rapla.net/" />
    </links>

    <body>
      <p>Four new wireless drivers were imported:</p>

      <p>
      <em>ipw</em>

      : driver for Intel PRO/Wireless 2100 adapters (MiniPCI). 
      <br />

      <em>iwi</em>

      : driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG adapters (PCI
      or MiniPCI). 
      <br />

      <em>ral</em>

      : driver for Ralink RT2500 wireless adapters (PCI or CardBus). 
      <br />

      <em>ural</em>

      : driver for Ralink RT2500USB wireless USB 2.0 adapters.</p>

      <p>The ipw and iwi drivers require firmwares to operate. 
      <br />

      These firmwares can't be redistributed with the base system due to
      license restrictions. 
      <br />

      See firmware licensing terms here: 
      <a href="http://ipw2100.sourceforge.net/firmware.php?fid=4">
      http://ipw2100.sourceforge.net/firmware.php?fid=4</a>

      . 
      <br />
      </p>

      <p>Ports which include the firmware images as well as the firmware
      loader are being worked on. 
      <br />

      A list of adapters supported by ral and ural can be found here: 
      <a href="http://ralink.rapla.net/">http://ralink.rapla.net/</a>

      .</p>
    </body>

    <help>
      <task>Create ports for ipw and iwi firmwares.</task>

      <task>Add IBSS support to iwi.</task>

      <task>Add WPA (802.11i) support to ipw and iwi.</task>

      <task>Add hardware encryption (WEP, TKIP and CCMP) support in ral
      and ural.</task>

      <task>Add automatic rate adaptation support to ural.</task>
    </help>
  </project>
</report>

