<?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>April-June</month>

    <year>2006</year>
  </date>

  <section>
    <title>Introduction</title>

    <p>With the release of FreeBSD 5.5 and FreeBSD 6.1, the second
    quarter of 2006 has been productive. Google is sponsoring 14 students
    to work on FreeBSD as part of their Summer of Code Program (most of
    which already submitted a report for elaboration on their
    projects).</p>

    <p>Sun's open-source software is starting to make its way into
    FreeBSD as a port of DTrace is nearing completion and a port to the
    UltraSparc T1 processor (which gives a great push to the ongoing SMP
    efforts). Having a powerful debugging tool combined with a CPU that
    can run up to 32 concurrent threads helps to identify scalability
    issues.</p>

    <p>BSDCan 2006 was yet again a smashing success and much was covered
    in the 2-day developer summit. As a product of the conference, a new
    focus on FreeBSD for the embedded sector has started. Various ARM
    boards are targeted, a MIPS32 port is gearing up and people are
    looking for other interesting platforms to port FreeBSD to.
    Preparation for the EuroBSDCon (in Milan, Italy) on November has
    already issued a call for papers.</p>

    <p>In addition, a lot of spring cleaning is taking place in the
    network stack. After conclusion of the KAME project, IPv6 code
    integration has been refocused and a fully locked port of SCTP is in
    the final stage of integration. Of course, all this goes without
    noting all the progress made with the other network projects.</p>

    <p>Please read below for more detailed news on the projects that
    happened in FreeBSD during the last three months. If you are
    interested in helping, consider the "Open Tasks lists" provided with
    some reports. In addition we would like to point you at the 
    <a href="http://www.freebsd.org/projects/ideas/">list of projects and
    ideas for volunteers</a>

    and hope to receive a status report from you next time.</p>

    <p>Thanks to all reporters for your excellent work and timing! Enjoy
    reading.</p>
  </section>

  <category>
    <name>soc</name>

    <description>Google summer of code</description>
  </category>

  <category>
    <name>proj</name>

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

  <category>
    <name>net</name>

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

  <category>
    <name>kern</name>

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

  <category>
    <name>docs</name>

    <description>Documentation</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='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/">BSDCan</url>
    </links>

    <body>
      <p>
      <a href="http://www.bsdcan.org/">BSDCan 2006</a>

      continues to impress. Again this year, we had a good collection of
      talks from a wide range of speakers. In all, we had over 200 people
      from 14 different countries.</p>

      <p>Our sponsorship pool continues to grow. This year we had
      sponsorship from: 
      <ul>
        <li>
          <a href="http://www.usenix.org/">USENIX</a>
        </li>

        <li>
          <a href="http://www.freebsdfoundation.org/">The FreeBSD
          Foundation</a>
        </li>

        <li>
          <a href="http://www.parse.com/">PARSE</a>
        </li>

        <li>
          <a href="http://www.ixsystems.com/">iXsystems</a>
        </li>

        <li>
          <a href="http://www.oreilly.com/">O'Reilly</a>
        </li>

        <li>
          <a href="http://www.stevens-tech.edu/">Stevens Institute of
          Technology</a>
        </li>

        <li>
          <a href="http://www.ncircle.com/">nCircle</a>
        </li>
      </ul>

      <br />

      The 
      <a href="http://www.bsdcan.org/2006/images/t-shirt.jpg">
      t-shirts</a>

      were very popular, with all of them going in very short time. Of
      course, it helped that this year they were free, courtesy of
      PARSE.</p>

      <p>The 2007 planning has already begun and we look forward to
      another popular and successful event.</p>

      <p>My thanks to the 2006 program committee, the speakers, the
      volunteers, the sponsors, and, of course, the attendees.</p>

      <p>See you at BSDCan 2007.</p>
    </body>
  </project>

  <project cat='misc'>
    <title>Release Engineering</title>

    <contact>
      <person>
        <name>
          <common>Release Engineering Team</common>
        </name>

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

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

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

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

    <body>
      <p>The release engineering (RE) team announced the availability of
      FreeBSD 5.5 and 6.1, both in May 2006. FreeBSD 5.5 is the last
      planned release from the RELENG_5 branch in CVS. For the most part,
      its main features consist of bugfixes, security patches, and minor
      updates. We encourage users to move towards the 6.x series of
      releases whenever practical. FreeBSD 6.1 is the latest of the
      releases to come from the RELENG_6 branch in CVS. It includes
      (among many other things) improved support for WiFi devices,
      additional network and disk controller drivers, and a number of
      fixes for filesystem stability. The next release to be issued from
      this branch will be FreeBSD 6.2, which is currently scheduled for
      September 2006.</p>

      <p>The RE team is currently in a ``between releases'' mode. Current
      activities include working with security-team@ on some errata fixes
      for the RELENG_6_1 branch and producing snapshots of HEAD and
      RELENG_6 at the start of each month.</p>

      <p>Several personnel changes have taken place recently. Scott Long
      has stepped down from his position on the RE team; we thank him for
      his considerable efforts over the past four years. In his place,
      Ken Smith has taken over the role of lead release engineer. Bruce
      A. Mah has rejoined the RE team after a two-year sabbatical.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Giant-Less USB framework</title>

    <contact>
      <person>
        <name>
          <given>Hans Petter</given>

          <common>Sirevaag Selasky</common>
        </name>

        <email>hselasky@c2i.net</email>
      </person>
    </contact>

    <links>
      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb&amp;HIDEDEL=NO">
      Current files</url>

      <url href="http://www.turbocat.net/~hselasky/usb4bsd">Easy to
      install tarballs</url>
    </links>

    <body>
      <p>For some time now I have been working on converting the existing
      USB device drivers to my new and mutex enabled USB API. I have
      converted "ulpt", "ums", "uhid", "ukbd", "ugen", "uaudio", and a
      few others. Around 10 USB device drivers are left to convert. Most
      of these are network device drivers.</p>

      <p>At the present moment I am working on getting scatter and
      gathering support working for all USB host controllers. Scatter and
      gathering means that one allocates PAGE_SIZE bytes of memory at a
      time, and then fills these memory blocks up as much as possible
      with USB host controller structures and buffers. This should solve
      problems allocating DMA-able memory when the system memory becomes
      fragmented.</p>
    </body>

    <help>
      <task>If anyone wants to help convert the remaining USB device
      drivers, please drop me an e-mail.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>SSE2 Kernel support</title>

    <contact>
      <person>
        <name>
          <given>Attilio</given>

          <common>Rao</common>
        </name>

        <email>attilio@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/projects/ideas/#p-memcpy">Project
      details</url>

      <url
      href="http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2006-05/msg00109.html">
      Ongoing development</url>
    </links>

    <body>
      <p>Some 
      <strong>FPU system</strong>

      and 
      <strong>kernel memcpy/copyin/copyout</strong>

      changes have been performed. In particular, a per-CPU save area has
      been introduced (protected with an interlock) in order to assure a
      stable saving mechanism. 
      <strong>copyout/copyin</strong>

      have changed in order to use vectorised version of 
      <strong>memcpy</strong>

      and an xmm version of memcpy has been provided.</p>
    </body>

    <help>
      <task>Benchmarks on different versions of xmm copy, in particular
      showing differences between UP and SMP architectures (evaluating
      possibility to add block prefetch, non-temporal hints usage,
      etc.)</task>

      <task>Modifying npxdna trap handler in order to recognise xmm
      environment usage and replace fxsave with 8-movdqa</task>
    </help>
  </project>

  <project cat='soc'>
    <title>BSNMP Bridge module</title>

    <contact>
      <person>
        <name>
          <given>Shteryana</given>

          <common>Shopova</common>
        </name>

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

    <links>
      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/soc%2dshteryana/bsnmp/usr.sbin/bsnmpd/modules/snmp%5fbridge">
      P4 workspace</url>

      <url href="http://wiki.freebsd.org/SnmpBridgeModule">Wiki
      page</url>
    </links>

    <body>
      <p>As part of my SoC 2006 project I am working on implementing a
      BRIDGE monitoring module for FreeBSD's BSNMP daemon. Initial
      prototyping is done and some kernel changes are coming to be able
      to access all needed data. In addition to IETF RFC 4188, which was
      designed for monitoring a single bridge, this snmp module will
      support monitoring of multiple bridge devices as supported by
      FreeBSD.</p>
    </body>

    <help>
      <task>Finish kernel changes and the code for the snmp
      module.</task>

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

  <project cat='proj'>
    <title>DTrace</title>

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

          <common>Birrell</common>
        </name>

        <email>jb@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.freebsd.org/~jb/dtrace/index.html" />
    </links>

    <body>
      <p>Anonymous enablings now work. There is a new option in the boot
      loader menu to load the DTrace modules and trace the kernel boot
      process.</p>

      <p>Sun Microsystems has been very supportive of the FreeBSD port
      and has generously provided a Sun Fire T2000 server to allow Kip
      Macy's sun4v port to be merged into the DTrace project tree.</p>

      <p>The DTrace project tree sources are now exported to
      cvsup10.freebsd.org</p>

      <p>Refer to the project page for more details.</p>
    </body>

    <help>
      <task>Current effort centres around making DTrace useful for the
      sun4v porting effort which has shown up scalability issues with the
      current FreeBSD SMP implementation. DTrace should be ideal for
      analysing those issues.</task>
    </help>
  </project>

  <project cat='proj'>
    <title>Embedded FreeBSD</title>

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

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

        <email>gnn@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.embeddedfreebsd.org/">Main Site</url>
    </links>

    <body>
      <p>There are several projects moving forward in the embedded area.
      For now the main location for new information is
      www.embeddedfreebsd.org. We have also created a new mailing list, 
      <a
      href="http://lists.freebsd.org/mailman/listinfo/freebsd-embedded">
      freebsd-embedded@freebsd.org</a>

      , which is meant to eventually replace the freebsd-small. A call
      was put out on small for people to move to embedded.</p>
    </body>

    <help>
      <task>Update Developers Handbook with information on building
      embedded versions of FreeBSD</task>

      <task>Help with the MIPS port</task>

      <task>Help with the ARM port</task>

      <task>Investigate an SH port (requested by folks in Japan where the
      Hitachi SH processor is quite popular in embedded)</task>
    </help>
  </project>

  <project cat="misc">
    <title>EuroBSDCon 2006 - November 10th - 12th, Milan, Italy</title>

    <contact>
      <person>
        <name>
          <given>Massimiliano</given>

          <common>Stucchi</common>
        </name>

        <email>stucchi@eurobsdcon.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.eurobsdcon.org">Official Website</url>
    </links>

    <body>
      <p>This year's EuroBSDCon will be held in Milan, Italy, on November
      10th through 12th.</p>

      <p>Hosted in the foggy northern Italy, the fifth EuroBSDCon aims at
      being a new successful chapter in the itinerant series of European
      BSD conferences.</p>

      <p>EuroBSDCon represents the biggest gathering for BSD developers
      from the old continent, as well as users and passionates from
      around the World. It is also a chance to share experiences,
      know-how, and cultures.</p>

      <p>For the first time, parallel to the main event, an event for
      wives/girlfriends/friends will be organised. It will consist of
      guided tours of the city of Milan, a probable trip to Como and
      visits to various museums. We're also working towards offering a
      show at the Teatro alla Scala.</p>

      <p>The FreeBSD developer summit will be also held on November
      10th.</p>
    </body>

    <help>
      <task>The Call For Papers is out, so everybody is invited to send
      in papers or tutorials that might be of interest to the
      community</task>

      <task>The Conference Organisers are also looking for sponsors. Feel
      free to contact oc@eurobsdcon.org in order to discover the
      different sponsoring opportunities.</task>
    </help>
  </project>

  <project cat='net'>
    <title>FAST_IPSEC Upgrade</title>

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

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

        <email>gnn@freebsd.org</email>
      </person>

      <person>
        <name>
          <given>Bjoern A.</given>

          <common>Zeeb</common>
        </name>

        <email>bz@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://sources.zabbadoz.net/freebsd/ipv6/fast-ipsec.html" />
    </links>

    <body>
      <p>Continuing to add IPv6 support to FAST_IPSEC. Test environment
      is now stable. Can build and run kernels with FAST_IPSEC and INET6
      enabled but IPSec in IPv6 is now broken and being worked on.</p>
    </body>

    <help>
      <task>Complete move to FAST_IPSEC type processing for IPv6. This is
      complicated by the structure of the IPv6 code itself which, unlike
      IPv4 splits transport and tunnel mode processing across the output
      routine.</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>FreshPorts has seen several new features recently: 
      <ul>
        <li>caching implemented at web application level to reduce load
        on the database server and to serve pages faster</li>

        <li>searching expanded to find all the ports that this maintainer
        maintains, and all the commits by a particular committer</li>
      </ul>

      <br />

      Most of the work lately has been optimisation, either at the
      database level or at the web application level.</p>

      <p>A 2U server was recently donated to the 
      <a href="http://www.freshports.org">FreshPorts</a>

      / 
      <a href="http://www.freshsource.org">FreshSource</a>

      / 
      <a href="http://www.freebsddiary.org/">FreeBSD Diary</a>

      / 
      <a href="http://www.bsdcan.org/">BSDCan</a>

      group. We have also received a RAID card. Now we're looking for
      some hard drives.</p>

      <p>Over the past few weeks, work has concentrated on benchmarking
      the new server and getting it ready for production. Eventually it
      will need a new home as I don't really want it running in my
      basement all the time (it's really loud!).</p>

      <p>Thanks to 
      <a href="http://www.ixsystems.com">iXsystems</a>

      and 
      <a href="http://www.3ware.com">3Ware</a>

      for their contributions to this project.</p>
    </body>

    <help>
      <task>We would like some more hardware (CPUs and HDD). Details 
      <a href="http://www.freebsddiary.org/sponsors-wanted.php">here</a>
      </task>
    </help>
  </project>

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

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

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

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

    <links>
      <url
      href="http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html">
      Announce.</url>

      <url href="http://people.freebsd.org/~pjd/patches/gjournal.patch">
      Patches for HEAD.</url>

      <url href="http://people.freebsd.org/~pjd/patches/gjournal6.patch">
      Patches for RELENG_6.</url>
    </links>

    <body>
      <p>GJournal is a GEOM class which provides journaling for GEOM
      providers. It can also be used to journal various file systems with
      just a minimal filesystem-specific portion of code. Currently only
      UFS journaling is implemented on top of gjournal. Being
      filesystem-independent and operating below the file system level,
      gjournal has no way to distinguish data from metadata, thus it
      journals both. One of the nice things about gjournal is that it
      works reliable even on disks with enabled write cache, which is
      often not the case for journalled file systems. And remember... fsck
      no more.</p>
    </body>

    <help>
      <task>I'm looking for feedback from users who can test gjournal in
      various workloads.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>gvirstor</title>

    <contact>
      <person>
        <name>
          <given>Ivan</given>

          <common>Voras</common>
        </name>

        <email>ivoras@freebsd.org</email>
      </person>
    </contact>

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

    <body>
      <p>The purpose of 
      <em>gvirstor</em>

      module is to provide the ability to create a virtual storage device
      of arbitrarily large size (typically several terabytes) which
      consists of an arbitrary number of physical storage devices
      (actually any lower-level GEOM providers, including RAID devices)
      of arbitrary size (typically 50 GB - 400 GB hard drives). Storage
      space from these components is carved into small chunks (for
      example 4 MB) and allocated (committed) to the virtual device on
      as-needed basis.</p>

      <p>Development has started and is progressing as planned (though a
      little bit slow). Metadata format and virtual storage allocation
      formats have been defined and more serious coding is in
      progress.</p>
    </body>

    <help>
      <task>Much user testing will be needed (though not
      currently)</task>
    </help>
  </project>

  <project cat='docs'>
    <title>FreeBSD list of projects and ideas for volunteers</title>

    <contact>
      <person>
        <name>
          <given>Joel</given>

          <common>Dahl</common>
        </name>

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

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

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

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

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

    <body>
      <p>The FreeBSD list of projects and ideas for volunteers is doing
      well. Several items were picked up by volunteers and have found
      their way into the tree. Others are under review or in progress. We
      are looking forward to hear about new ideas, people willing to act
      as technical contacts for generic topics such as USB or specific
      entries (already existing or newly created) and suggestions for
      existing entries or completion reports for (parts of) an entry.</p>
    </body>

    <help>
      <task>Add more ideas.</task>

      <task>Find more technical contacts.</task>

      <task>Find people willing to review/test implementations of
      (somewhat) finished items.</task>
    </help>
  </project>

  <project cat='net'>
    <title>IPv6 cleanup</title>

    <contact>
      <person>
        <name>
          <given>Bjoern A.</given>

          <common>Zeeb</common>
        </name>

        <email>bz@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url href="http://sources.zabbadoz.net/freebsd/ipv6/">Project
      summary</url>

      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/bz/ipv6">
      P4 workspace for future changes</url>
    </links>

    <body>
      <p>Initial changes include: 
      <ul>
        <li>Changed ip6_sprintf to no longer return a static buffer.</li>

        <li>Started to adopt in6_pcb* code to what we have for legacy
        IP.</li>
      </ul>

      <br />

      Next steps will be to reduce the number of global variables and
      caches.</p>
    </body>

    <help>
      <task>Cleanup code.</task>

      <task>Make everything MPSafe.</task>

      <task>Enhance things and add new features.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>IPv6 Vulnerabilities</title>

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

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

        <email>gnn@freebsd.org</email>
      </person>

      <person>
        <name>
          <given>Cl&#233;ment</given>

          <common>Lecigne</common>
        </name>

        <email>clemun@GMAIL.COM</email>
      </person>
    </contact>

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

    <body>
      <p>Clement has been working both with libnet and gnn's Python based
      packet library (PCS) to produce code to test for vulnerabilities in
      IPv6. To Clement has found some issues, all of which have been
      reported to his mentor and to Security Officer at FreeBSD.org
      Vulnerabilities will not be reported here.</p>
    </body>

    <help>
      <task>Get 0.1 of PCS on to SourceForge for wider use.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Jail Resource Limits</title>

    <contact>
      <person>
        <name>
          <given>Chris</given>

          <common>Jones</common>
        </name>

        <email>cdjones@freebsd.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>Project is in development with initial working software expected
      mid-July 2006. CPU limits will be implemented with a hierarchical
      scheduler: (initially) using a round-robin scheduler to select
      which jail to run a task in and then delegating which task in the
      jail to be run to a per-jail scheduler.</p>
    </body>

    <help>
      <task>Complete round-robin inter-jail scheduler (with existing 4BSD
      schedulers implemented per jail).</task>

      <task>Add hooks for memory tracking.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>K Kernel Meta-Language</title>

    <contact>
      <person>
        <name>
          <given>Spencer</given>

          <common>Whitman</common>
        </name>

        <email>joecat@cmu.edu</email>
      </person>

      <person>
        <name>
          <given>Poul-Henning</given>

          <common>Kamp</common>
        </name>

        <email>phk@FreeBSD.ORG</email>
      </person>
    </contact>

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

    <body>
      <p>A simple lexer and parser have almost been completed. Also
      significant planing for future additions to K have been thought
      up.</p>
    </body>

    <help>
      <task>Finish the lexer and parser</task>

      <task>Implement the #! preprocessor function</task>

      <task>Add lint like functionality to the preprocessor</task>

      <task>Add style(9) checking to the preprocessor</task>

      <task>Allow for detection of unused #includes</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Linuxolator kernel update to match functionality of
    2.6.x</title>

    <contact>
      <person>
        <name>
          <given>Roman</given>

          <common>Divacky</common>
        </name>

        <email>rdivacky@freebsd.org</email>
      </person>

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

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

        <email>netchild@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url href="http://wiki.freebsd.org/RomanDivacky">Summer of Code
      proposal</url>
    </links>

    <body>
      <p>FreeBSD linux emulation layer (linuxolator) currently implements
      most of the functionality necessary to emulate 2.4.2 linux kernel,
      but linux world has moved forward and current linux world requires
      2.6.x features. The aim of this SoC task is to make Fedora Core 4
      linux-base to be able to run with 2.6.x kernel. Currently this
      means extending clone() syscall and implement pthread related
      things. This involves TLS implementation (sys_set_thread_area
      syscall) and possibly tid manipulation (used for pthread_join etc.)
      and finally futexes (linux fast user-space mutexes implementation).
      This should enable pthread-linked programs to work. After this is
      done there may be other things necessary to implement however, only
      time will tell. I am funded by google.com in their SoC to do this
      work and I'll continue to work on this after the summer hopefully
      as a part of my MSc. thesis.</p>
    </body>

    <help>
      <task>Finish the TLS thing + other thread related things (tid comes
      to mind and looks necessary for pthread to work)</task>

      <task>Futexes also look necessary for pthread to work</task>

      <task>maybe other things to be able to run basic programs under
      2.6.16 linuxolator</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Improving Ports Collection</title>

    <contact>
      <person>
        <name>
          <given>G&aacute;bor</given>

          <common>K&ouml;vesd&aacute;n</common>
        </name>

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

    <links>
      <url
      href="http://wiki.freebsd.org/G%C3%A1borK%C3%B6vesd%C3%A1n">
      Wiki page about the project</url>

      <url href="http://wiki.freebsd.org/DESTDIR">Explaining
      DESTDIR</url>

      <url href="http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/98105">
      ports/98105</url>
    </links>

    <body>
      <p>The improved support for the i386 binaries are ready for -exp
      run. It only allows installing such ports on amd64 and ia64 when
      there's a compatibility layer compiled into the kernel and the
      32-bit libraries are installed under /usr/lib32.</p>

      <p>The DESTDIR support are in progress. It works for the simplest
      ports without USE_* that don't have a [pre|do|post]-install target.
      There are more complicated issues with e.g. conflict checking in
      DESTDIR, deinstalling from DESTDIR, those have to be fixed as
      well.</p>
    </body>

    <help>
      <task>DESTDIR issues should be fixed.</task>

      <task>All ports should be examined whether they respect CC/CFLAGS,
      and the erroneous ones should be fixed.</task>

      <task>Fetch scripts should be taken out of bsd.port.mk to be
      separate scripts.</task>

      <task>A tool should be written that makes possible to cross-compile
      ports.</task>

      <task>A good plist generator tool should be written for porters or
      the old one in ports/Tools/scripts should be updated.</task>
    </help>
  </project>

  <project cat='docs'>
    <title>Hungarian translation of the webpages</title>

    <contact>
      <person>
        <name>
          <given>G&aacute;bor</given>

          <common>K&ouml;vesd&aacute;n</common>
        </name>

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

    <links>
      <url href="http://gabor.t-hosting.hu/data/hu/">Current status</url>
    </links>

    <body>
      <p>The translated webpage is almost ready now. This Hungarian
      translation is a "lite" version of the original English webpages,
      since there are parts that are irrelevant for the Hungarian
      community, or has pieces of data that change quickly, so it's no
      use to translate these pages now, maybe later, if we have more
      Hungarian contributors, but this webpage would be a good starting
      point in translating the documentations, and we need a good place
      to put translated documentations anyway.</p>

      <p>I'm going to be very busy with SoC this summer, but I'll try to
      find people that can help me out in this project. Any help
      appreciated.</p>
    </body>

    <help>
      <task>The remaining important pages should be translated.</task>

      <task>The press/media/news sections should be restructured somehow
      to being fed from the English webapges, since we don't have too
      much Hungarian resource to make these up to date.</task>

      <task>There's a rendering issue when browsing the pages with
      JavaScript enabled, but this can be server-side for me, this should
      be investigated as well.</task>
    </help>
  </project>

  <project cat='net'>
    <title>Multi-IP v4/v6 jails</title>

    <contact>
      <person>
        <name>
          <given>Bjoern A.</given>

          <common>Zeeb</common>
        </name>

        <email>bz@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/bz/jail">
      P4 workspace</url>
    </links>

    <body>
      <p>As an intermediate step until FreeBSD will have full network
      stack virtualisation this work shall provide support for multi-IP
      IPv4/v6 jails.</p>

      <p>These changes are based on Pawel Jakub Dawidek's work for
      multi-IPv4 jails and some initial work from Olivier Houchard for
      single-IPv6 jails.</p>

      <p>The changes need some more testing but basically things
      work.</p>

      <p>This is not considered to be the right thing todo so do 
      <b>not</b>

      ask for official support or if this will be committed to the
      FreeBSD source repository. 
      <br />

      After some more cleanup of non-jail related IPv6 changes I will
      publish a patch for HEAD and perhaps RELENG_6 for everyone who
      wants to give it a try anyway.</p>
    </body>

    <help>
      <task>(IPv6) related security checks.</task>

      <task>Write some tests. Especially IPv6 changes need more
      testing.</task>

      <task>Check what general changes might need merging to HEAD.</task>
    </help>
  </project>

  <project cat='net'>
    <title>FreeBSD NFS Status Report</title>

    <contact>
      <person>
        <name>
          <given>Chuck</given>

          <common>Lever</common>
        </name>

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

    <body>
      <p>Mohan Srinivasan committed his changes to make the NFSv2/3 client
      MP safe to HEAD this quarter. Changes may be back-ported to 6.x
      soon.</p>

      <p>Robert Watson and Chuck Lever held a discussion about the future
      of the in-kernel NFSv4 client during BSDCan 2006. The current NFSv4
      client is unmaintained. Chuck also pointed out the long series of
      unfixed PRs against the legacy client (NFSv2/3). These are at the
      top of his priority list. Robert is also interested in making
      NFSv4-style ACLs the lingua franca for FreeBSD file systems. There
      was some discussion about integrating Rick MacKlem's NFSv4 server
      into 7.x.</p>

      <p>Chuck Lever became a full source committer during this
      quarter.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>Nss-LDAP importing and nsswitch subsystem improvement</title>

    <contact>
      <person>
        <name>
          <given>Michael</given>

          <common>Bushkov</common>
        </name>

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

    <links>
      <url
      href="http://wiki.freebsd.org/LdapCachedDetailedDescription">
      Wiki-pages containing an up-to-date information about project
      implementation details.</url>

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

    <body>
      <p>The basic goals of this SoC 2006 project are moving
      nsswitch-modules out of the libc, extending the caching daemon and
      importing nss_ldap into the base source tree. 2 milestones of the
      project are currently completed.</p>

      <p>1. Nss-modules were successfully moved out of the libc into the
      separate dynamic libraries. In order for static binaries to work
      properly (they can't use dynamic nss-modules), nss-modules are
      linked statically into the libc.a. As the side-effect of
      nss-modules separation, getipnodeby***() functions were rewritten
      to use gethostby***() functions and not the nsdispatch(3) call.
      Caching daemon's "perform-actual-lookups" option was extended to
      support all implemented nsswitch databases.</p>

      <p>2. A set of regressions tests was made to test nsswitch-related
      functions. These tests are also capable of testing the stability of
      these functions' behaviour after the system upgrade.</p>
    </body>

    <help>
      <task>Import nss_ldap into the sources tree.</task>

      <task>Improve the caching daemon's performance.</task>
    </help>
  </project>

  <project cat='vendor'>
    <title>pfSense</title>

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

          <common>Ullrich</common>
        </name>

        <email>sullrich@gmail.com</email>
      </person>
    </contact>

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

    <body>
      <p>pfSense is rapidly approaching release. We are down to a
      handfull of bugs that should be fixed in the coming weeks. We
      should have a release around the time of our 2nd annual hackathon
      which is taking place on July 21st - July 28th. Many exciting
      sub-projects are taking place within pfSense and the project is
      gaining new developers monthly.</p>
    </body>

    <help>
      <task>
      <a href="http://cvstrac.pfsense.com/rptview?rn=6">
      http://cvstrac.pfsense.com/rptview?rn=6</a>

      lists the remaining open bugs.</task>
    </help>
  </project>

  <project cat='bin'>
    <title>Low-overhead performance monitoring tools</title>

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

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

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

    <links>
      <url href="http://wiki.freebsd.org/LibElf">Wiki page tracking
      LibELF</url>

      <url href="http://wiki.freebsd.org/PmcTools">Wiki page for
      PmcTools</url>

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

    <body>
      <p>As an intermediate step towards implementing support for
      callgraphs and cross-architecture performance measurements, I am
      creating a BSD-licensed library for ELF parsing &amp; manipulation.
      This library will implement the SysV/SVR4 (g)ELF[3] API.</p>

      <p>Current status: Implementation of the library is in progress. A
      TET-based test suite for the API and manual pages documenting the
      library's interfaces are being concurrently created.</p>

      <p>Work is being done in FreeBSD's Perforce repository. I hope to
      be ready for general review by the end of July '06.</p>
    </body>

    <help>
      <task>Reviewers are needed for the code and the test suite. If you
      have extensions to the stock SysV/SVR4 ELF(3) API that you would
      like to see in -lelf, please send mail.</task>
    </help>
  </project>

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

    <contact>
      <person>
        <name>
          <given>Erwin</given>

          <common>Lansing</common>
        </name>

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

    <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://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/">
      Contributing to the FreeBSD Ports Collection</url>

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

      <url href="http://people.freebsd.org/~fenner/portsurvey/">FreeBSD
      ports unfetchable distfile survey (Bill Fenner's report)</url>

      <url href="http://beta.inerd.com/portscout/">portscout</url>

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

      <url href="http://tinderbox.marcuscom.com">marcuscom
      tinderbox</url>
    </links>

    <body>
      <p>During this time, a huge number of ports PRs were committed,
      bringing us back down below 800 for the first time since the
      5.5/6.1 release cycle. This is due to a great deal of work,
      especially from some of our newest committers.</p>

      <p>This is all the more notable given the fact that we have been
      adding new ports at a rapidly accelerating rate. We have now
      exceeded the 15,000 port mark!</p>

      <p>Three sets of changes have been added to the infrastructure,
      including updates of default versions of MySQL, PHP, LDAP, and
      linux_base, and numerous bugfixes and improvements. About 2 dozen
      portmgr PRs were closed due to this.</p>

      <p>In addition, a large-impact commit was made that attempts to
      move us to a single libtool that is as unmodified from 'stock'
      libtool as we can. Plans are also in place to do this for the
      autotools.</p>

      <p>Several people are at work on implementing the modularised xorg
      ports. Most of the work is done but several key pieces remain. Once
      this is finished, an -exp regression test will be needed (most
      likely, more than one :-) ) It is possible that before this we will
      need to do a regression test that moves X11BASE back into
      LOCALBASE. This is still under study.</p>

      <p>G&aacute;bor K&ouml;vesd&aacute;n started a Google Summer of Code
      project on some highly needed improvements on the ports infrastructure
      (see elsewhere in this report). As this is a long term project, gtetlow
      kindly imported the most important ports infrastructure files into
      perforce to ease development. Other developers are encouraged to
      use perforce for ports development, especially as it can help
      keeping patches up-to-date while going stale in GNATS. Even though
      linimon has been pushing hard on running experimental builds on the
      test cluster, it will take some time to work through the
      backlog.</p>

      <p>erwin added a ports section to the list of projects and ideas
      for volunteers at the FreeBSD website. Have a look if you want to
      work on the ports system. Don't hesitate to send additional ideas,
      and committers are encouraged to add themselves as technical
      contacts.</p>

      <p>sem adopted portupgrade after it had been neglected for some
      time and has been very active on upgrades and bugfixing.</p>

      <p>dougb has continued to enhance his portmaster script and people
      are finding success with it; although not designed to be as
      full-featured as portupgrade, it does seem to be easier to
      understand and use.</p>

      <p>shaun has contributed portscout, a scanner for updated
      distfiles, to the ports collection.</p>

      <p>marcus upgraded GNOME to 2.14.1.</p>

      <p>As well, there have been new releases of the ports tinderbox
      code.</p>

      <p>edwin has been hard at work on a PR-autoassigner for ports PRs,
      which has saved a lot of time and been well-received. It has now
      been installed on a freebsd.org machine (hub).</p>

      <p>linimon has been more active in pursuing maintainer-timeouts,
      and has reset a number of inactive maintainers, with more in the
      pipeline. The intent is to try to reduce the number of PRs that sit
      around unanswered for two weeks. In almost all cases the resets are
      due to no response at all; maintainers who are merely "busy" are
      not the source of most of these problems, and deserve the benefit
      of the doubt. Some of the maintainers that have been reset haven't
      contributed in months or even years.</p>

      <p>We have added 10 (!) new committers since the last report.</p>
    </body>

    <help>
      <task>We need help getting back to our modern low of 500
      PRs.</task>

      <task>We have over 4,000 unmaintained ports (see, for instance, 
      <a
      href="http://portsmon.freebsd.org/portsconcordanceformaintainer.py?maintainer=ports@FreeBSD.org">
      the list on portsmon</a>

      ). We are always looking for dedicated volunteers to adopt at least
      a few ports.</task>

      <task>We can always use help with infrastructural enhancements. See
      the ports section of 
      <a href="http://www.freebsd.org/projects/ideas/">the list of
      projects and ideas</a>

      .</task>
    </help>
  </project>

  <project cat='vendor'>
    <title>BSDInstaller</title>

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

          <common>Turner</common>
        </name>

        <email>soc-andrew@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://wiki.freebsd.org/moin.cgi/BSDInstaller" />
    </links>

    <body>
      <p>Since the last status report ports have been created for all
      parts of the BSDInstaller except the backend.</p>

      <p>A snapshot of the BSDInstaller was released during this quarter.
      This has shown a number of bugs with the installation process. Most
      have now been fixed.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Giant-Less UFS with Quotas</title>

    <contact>
      <person>
        <name>
          <given>Konstantin</given>

          <common>Belousov</common>
        </name>

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

    <links>
      <url href="http://people.freebsd.org/~kib/quotagiant" />
    </links>

    <body>
      <p>The patches to allow UFS operate with quotas in Giant-less mode
      are brewed for long now. Since recent huge pile of fixes into
      snapshots code, I think the problems you could encounter are caused
      solely by the patch.</p>

      <p>Aside performance benefits, patch has another one, much more
      valuable. It makes UFS operating in one locking regime whatever
      options are compiled into kernel. I think, in long term, that would
      lead to better stability of the system.</p>
    </body>

    <help>
      <task>I need testers feedback. Both stability reports and
      performance measurements are welcomed !</task>
    </help>
  </project>

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

    <contact>
      <person>
        <name>
          <given>Boris</given>

          <common>Samorodov</common>
        </name>

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

      <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>emulation@FreeBSD.org</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>We updated the default linux base port to Fedora Core 4 and the
      default linux X11 libs port to the X.org RPM in FC4.</p>

      <p>An update to FC5 or FC6 has to wait until the kernel got support
      for syscalls of a newer linux kernel. See the corresponding SoC
      project report for more.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Sound subsystem improvements</title>

    <contact>
      <person>
        <name>
          <given>Ariff</given>

          <common>Abdullah</common>
        </name>

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

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

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

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

      <person>
        <name>
          <given>Multimedia</given>

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

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

    <links>
      <url href="http://people.FreeBSD.org/~ariff/">Some patches.</url>

      <url href="http://www.FreeBSD.org/projects/ideas/">The FreeBSD
      Project Ideas List.</url>

      <url href="http://www.leidinger.net/FreeBSD/hdac_20060525.tbz">
      Rudimentary HDA support.</url>
    </links>

    <body>
      <p>Since the last status report we fixed some more bugs, added
      basic support for envy24 chips and cleaned up the source for the
      emu10kx driver in the ports to make it ready for import into the
      base system.</p>

      <p>We also got some patches with a little bit of infrastructure for
      Intel HDA support. It's not finished and also not usable by end
      users yet.</p>
    </body>

    <help>
      <task>Have a look at the sound related entries on the ideas
      list.</task>

      <task>sndctl(1): tool to control non-mixer parts of the sound
      system (e.g. spdif switching, virtual-3D effects) by an user
      (instead of the sysctl approach in -current); pcmplay(1),
      pcmrec(1), pcmutil(1).</task>

      <task>Plugable FEEDER infrastructure. For ease of debugging various
      feeder stuff and/or as userland library and test suite.</task>

      <task>Support for new hardware (envy24, Intel HDA).</task>
    </help>
  </project>

  <project cat='kern'>
    <title>XFS for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Russell</given>

          <common>Cattelan</common>
        </name>

        <email>cattelan@xfs.org</email>
      </person>

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

          <common>Kabaev</common>
        </name>

        <email>kan@freebsd.org</email>
      </person>

      <person>
        <name>
          <given>Craig</given>

          <common>Rodrigues</common>
        </name>

        <email>rodrigc@freebsd.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.freebsd.org/~rodrigc/xfs/">XFS for
      FreeBSD</url>
    </links>

    <body>
      <p>The XFS for FreeBSD project is an effort to port the publicly
      available GPL'd sources to SGI's XFS filesystem to FreeBSD.</p>

      <p>In December, we imported a version of XFS into FreeBSD-CURRENT
      which allows FreeBSD to mount an XFS filesystem as read-only.</p>

      <p>As a side effort, we have been continuing on the work that PHK
      started to clean up the mount code in FreeBSD. We can use the
      existing FreeBSD mount(8) utility to mount an XFS partition,
      without introducing a new mount_xfs utility.</p>
    </body>

    <help>
      <task>We need to implement support for writing to XFS
      partitions</task>
    </help>
  </project>

  <project cat='net'>
    <title>SCTP Integration</title>

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

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

        <email>gnn@freebsd.org</email>
      </person>

      <person>
        <name>
          <given>Randall</given>

          <common>Stewart</common>
        </name>

        <email>rrs@cisco.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.sctp.org/">Stream Transmission Control
      Protocol</url>
    </links>

    <body>
      <p>For the last several months Randall Stewart has been working in
      HEAD and STABLE to get us ready to integrate the SCTP protocol
      (Stream Transmission Control Protocol) into FreeBSD. He is
      currently working on a patch to share with a wider audience but
      needs to do some integration work first. Randall has a provisional
      commit bit and will be working with gnn on getting code committed
      to the HEAD of the tree.</p>
    </body>

    <help>
      <task>When this gets integrated it needs lots of testers.</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 the time since the last status report, four security
      advisories have been issued concerning problems in the base system
      of FreeBSD; of these, one problem was "contributed" code, while
      three were in code maintained within FreeBSD. The Vulnerabilities
      and Exposures Markup Language (VuXML) document has continued to be
      updated by the Security Team and Ports Committers documenting new
      vulnerabilities in the FreeBSD Ports Collection; since the last
      status report, 71 new entries have been added, bringing the total
      up to 757.</p>

      <p>The following FreeBSD releases are supported by the FreeBSD
      Security Team: FreeBSD 4.11, FreeBSD 5.3, FreeBSD 5.4, FreeBSD 5.5,
      FreeBSD 6.0, and FreeBSD 6.1. The respective End of Life dates of
      supported releases are listed on the web site; of particular note,
      FreeBSD 5.3 and FreeBSD 5.4 will cease to be supported at the end
      of October 2006, while FreeBSD 6.0 will cease to be supported at
      the end of November 2006.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>Gvinum improvements</title>

    <contact>
      <person>
        <name>
          <given>Ulf</given>

          <common>Lilleengen</common>
        </name>

        <email>lulf@stud.ntnu.no</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>I have been working on porting missing features in gvinum from
      vinum, as well as adding new features.</p>

      <p>So far the resetconfig, detach, dumpconfig, setstate (on plexes
      and volumes) and stop commands have been implemented, as well as
      some other minor fixes. The attach command is currently being
      implemented, and started on disk-grouping. Currently most of this
      is in p4, but patches will be submitted as soon as possible.</p>
    </body>
  </project>

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

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

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

        <email>sam@errno.com</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>The wireless support has been stable for a while so most work has
      focused on bug fixing and improving legacy drivers.</p>

      <p>Max Laier and I worked on improving support for Intel wireless
      cards. The results of this work included significant improvements
      to the iwi(4) driver (for 2195/2200 parts) and the firmware(9)
      facility for managing loadable device firmware. There is also an
      updated ipw(4) that has improvements similar to those done for iwi
      that is in early test. Support for the latest Intel devices, the
      3945 pci-express cards, is planned for later this summer.</p>

      <p>Atheros support was updated with a new hal that fixes a few
      minor issues and provides known working builds for SPARC, PPC, and
      ARM platforms. There is also working MIPS support that will be used
      when the MIPS port is ready to test. Otherwise one useful bug was
      fixed that affected AP operation with associated stations operating
      in power save mode.</p>

      <p>wpa_supplicant and hostapd were updated to the latest stable
      build releases from Jouni Malinen.</p>

      <p>Experimental changes to support injection of raw 802.11 frames
      using bpf were posted for comment. This work was done in
      collaboration with Andrea Bittau.</p>
    </body>

    <help>
      <task>Legacy drivers such as wi are languishing and need
      maintainers. This is prerequisite to bringing in new 802.11
      features such as improved scanning and virtual ap.</task>
    </help>
  </project>

  <project cat='vendor'>
    <title>xscale board buy</title>

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

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

        <email>sam@errno.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.gateworks.com/avila_gw2348_4.htm" />

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

    <body>
      <p>With the help of Jim Thompson of Netgate ( 
      <a href="http://www.netgate.com/">http://www.netgate.com/</a>

      ) the FreeBSD Foundation arranged a purchase of xscale-based boards
      for folks interested in ARM support. Developers were able to
      purchase boards at a reduced cost. The goals were to accelerate
      and/or improve support for the ARM platform and to set forth at
      least one board as a reference platform for the ARM support.
      Netgate will be stocking lower-cost models of the board later in
      the year (a special order was made for boards with only 2 mini-pci
      slots).</p>
    </body>
  </project>

  <project cat='soc'>
    <title>Interrupt handling</title>

    <contact>
      <person>
        <name>
          <given>Paolo</given>

          <common>Pisati</common>
        </name>

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

    <body>
      <p>With the introduction of fine grained locking in the SMPng
      project, the FreeBSD kernel went under a major redesign, and many
      subsystem changed significantly with it. In particular, device
      driver's interrupt context ("the bottom half") had the necessity to
      synchronise with process context ("the top half") and share data in
      a consistent manner without using spl*(). To overcome this problem,
      a new interrupt model based around interrupt threads was employed,
      together with a fast interrupt model dedicated to particular driver
      handlers that don't block on locks (i.e. serial port, clock,
      etcetc). Unfortunately, even if the interrupt thread model proved
      to be a reliable solution, its performance was not on par with
      the pre SMPng era (4.x), and thus others solutions were
      investigated, with interrupt filtering being one of that.</p>

      <p>As part of my Summer of Code 2006 work, I'm implementing
      interrupt filtering for FreeBSD, and when the framework will be in
      place I'll compare the performance of filters, against all the
      previous models: pre-SMPng(4.x), ithread and polling.</p>

      <p>The most important modifications to the src tree so far were: 
      <ul>
        <li>made PPC accept more than one FAST handler per irq line
        (previously INTR_FAST implied INTR_EXCL)</li>

        <li>converted all the INTR_FAST handlers to be filters: return an
        error code to note what they did (FILTER_HANDLED/FILTER_STRAY)
        and if they need more work to do (FILTER_SCHEDULE_THREAD)</li>

        <li>moved part of the interrupt execution code from MD code to
        kern_intr.c::intr_filter_loop()</li>

        <li>broke newbus API: bus_setup_intr() grew a new filter
        parameter of type "int driver_filter_t(void*)".</li>

        <li>converted all the buses that override bus_setup_intr() to
        handle filters</li>

        <li>converted all the normal ithread drivers to provide a NULL
        filter funcion</li>
      </ul>

      <br />

      The next milestone is to have all the different models (filters
      only, ithread only and filter + ithread) work together
      reliably.</p>
    </body>

    <help>
      <task>Arm is largely untested</task>

      <task>Sparc64 needs more work on low level (.s) interrupt
      routine</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>

    <links>
      <url href="http://www.freebsd.org/platforms/ppc.html" />
    </links>

    <body>
      <p>The project is slowly starting to ramp up after a long
      move-induced hiatus.</p>

      <p>Alan Cox has almost completed making the pmap module
      Giant-free.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>TrustedBSD Audit</title>

    <contact>
      <person>
        <name>
          <given>Robert</given>

          <common>Watson</common>
        </name>

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

      <person>
        <name>
          <given>Wayne</given>

          <common>Salamon</common>
        </name>

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

      <person>
        <name>
          <given>Christian</given>

          <common>Peron</common>
        </name>

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

    <links>
      <url href="http://www.TrustedBSD.org/audit.html">TrustedBSD Audit
      Web Page</url>
    </links>

    <body>
      <p>TrustedBSD Audit provides fine-grained security event auditing
      in FreeBSD 7.x, with a planned merge to 6.x for FreeBSD 6.2. Work
      performed in the last three months: 
      <ul>
        <li>Per audit pipe preselection allows IDS applications to
        configure audit record selection per-pipe, new auditpipe.4
        document.</li>

        <li>audit_submit library call to reduce complexity of adding
        audit support to applications.</li>

        <li>Significant cleanup, bug fixing, locking improvements, token
        parsing and generation improvements.</li>

        <li>Solaris subject token compatibility, extended address
        support.</li>

        <li>Auditing of extended attributes calls, ACL support a work in
        progress.</li>

        <li>OpenBSM 1.0 alpha 7 integrated into CVS.</li>

        <li>OpenBSM test tools in progress.</li>

        <li>Experimental auditeventd which allows shared object plug-ins
        to subscribe to live audit events via a shared pipe in order to
        support the easy authoring of simple intrusion detection and
        monitoring components.</li>
      </ul>
      </p>
    </body>

    <help>
      <task>Bring audit event daemon API and implementation to maturity.
      Currently these are not installed by default in the CVS-merged
      version.</task>

      <task>Complete system call coverage.</task>

      <task>Allow finer-grained configuration of what is audited:
      implement control flags regarding paths, execve arguments,
      environmental variables.</task>

      <task>Support for auditing MAC policy data.</task>

      <task>Additional user space application coverage, such as
      application layer audit events from adduser, rmuser, pw,
      etc.</task>
    </help>
  </project>
</report>

