<?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>2007</year>
  </date>

  <section>
    <title>Introduction</title>

    <p>This report covers FreeBSD related projects between April and
    June 2007. Again an exciting quarter for FreeBSD. In May we saw one
    of the biggest developers summits to date at 
    <a href="http://www.bsdcan.org/2007/">BSDCan</a>

    , our 25 Google Summer of Code students started working on 
    <a href="http://www.freebsd.org/projects/summerofcode-2007.html">
    their projects</a>

    - progress reports are available below, and finally the 7.0 release
    cycle was started three weeks ago.</p>

    <p>If your are curious about what's new in FreeBSD 7.0 we suggest
    reading Ivan Voras' excellent summary at: 
    <a href="http://ivoras.sharanet.org/freebsd/freebsd7.html">
    http://ivoras.sharanet.org/freebsd/freebsd7.html</a>

    and of course these reports.</p>

    <p>The next gathering of the BSD community will be at 
    <a href="http://2007.eurobsdcon.org/">EuroBSDCon in Copenhagen</a>

    , September 14-15. More details about the conference and the
    developer summit are available in the respective reports below.</p>

    <p>Thanks to all the reporters for the excellent work! We hope you
    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>team</name>

    <description>FreeBSD Team Reports</description>
  </category>

  <category>
    <name>kern</name>

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

  <category>
    <name>net</name>

    <description>Network Infrastructure</description>
  </category>

  <category>
    <name>vendor</name>

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

  <category>
    <name>misc</name>

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

  <project cat='net'>
    <title>Multi-link PPP daemon (MPD)</title>

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

          <common>Motin</common>
        </name>

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

    <links>
      <url href="http://sourceforge.net/projects/mpd/">Project
      home</url>

      <url href="http://mpd.sourceforge.net/doc/mpd5.html">
      ChangeLog</url>
    </links>

    <body>
      <p>Mpd-4.2 has been released. It includes many new features,
      performance improvements and fixes.</p>

      <p>The most significant and unique new feature is a link repeater
      functionality. It allows mpd to accept incoming connection of any
      supported type and forward it out as same or different type
      outgoing connection. As example, this functionality allows mpd to
      implement real LAC with accepting incoming PPPoE connection from
      client and forwarding it using L2TP tunnel to LNS. All other
      software L2TP implementations I know is only a LAC emulators
      without real incoming calls forwarding abilities.</p>

      <p>Also mpd-4.2 presents:</p>

      <ul>
        <li>PPTP listening on multiple different IPs,</li>

        <li>L2TP tunnel authentication with shared secret,</li>

        <li>fast traffic filtering, shaping and rate-limiting using
        ng_bpf and ng_car,</li>

        <li>new 'ext-auth' auth backend as full-featured local
        alternative to 'radius-auth',</li>

        <li>NetFlow generation for both incoming and outgoing packets
        same time.</li>
      </ul>

      <p>Replacing external ifconfig and route calls with their
      internal implementations and other optimizations in 4.2 gave
      significant performance boost in session management. Newly
      implemented overload protection mechanism partially drops
      incoming connection requests for periods of critical load by
      monitoring daemon's internal message queue. As result, simple
      2GHz P4 system is now able to accept, authenticate and completely
      process spike of 1000 concurrent PPPoE connections in just a 30
      seconds.</p>
    </body>

    <help>
      <task>Implement dynamic link/bundle creation.</task>

      <task>Auth proxying support in repeater mode. It is required for
      some LAC/PAC and Tunnel Switching Aggregator (TSA) setups.</task>

      <task>Remove static phys - link - bundle and phys - repeater
      relations. Implement ability to differentiate incoming
      connections processing depending on user login, domain and/or
      other parameters.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Distributed Logging Daemon</title>

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

          <common>Mikhailov</common>
        </name>

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

      <person>
        <name>
          <given>Bjoern</given>

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

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

    <links>
      <url
      href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=232192+0+/usr/local/www/db/text/2007/freebsd-hackers/20070527.freebsd-hackers">
      Description of the project design</url>

      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/karma%5faudit/dlog&amp;HIDEDEL=NO">
      Perforce repository for project hosting</url>
    </links>

    <body>
      <p>The basic idea behind this project is to implement secure and
      reliable log file shipping to remote hosts. While the
      implementation focuses on audit logs, the goal is to build tools
      that will make it possible to perform distributed logging for any
      application by using a simple API and linking with a shared
      library.</p>
    </body>

    <help>
      <task>Network protocol implementation</task>

      <task>Spooling</task>

      <task>SSL support</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Porting OpenBSD's sysctl Hardware Sensors Framework to
    FreeBSD</title>

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

          <common>Murenin</common>
        </name>

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

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

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

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

    <links>
      <url
      href="http://mojo.ru/us/GSoC2007.FreeBSD.cnst-sensors.proposal.html">
      Port OpenBSD's sysctl hw.sensors framework to FreeBSD, original
      proposal for GSoC2007</url>

      <url href="http://cnst.livejournal.com/tag/GSoC2007">cnst's
      GSoC2007 blog</url>

      <url href="http://cnst.livejournal.com/data/atom?tag=GSoC2007">
      cnst's GSoC2007 atom feed</url>

      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/cnst-sensors/">
      cnst-sensors in soc2007 in perforce</url>
    </links>

    <body>
      <p>OpenBSD includes sysctl hw.sensors framework since 2003; since
      2005 the frameworks supports raid drives and most known i2c
      sensors; since 2006 the framework is redesigned with a sensor
      device concept in mind to accommodate continued growth. Consists
      of kernel api, sysctl(3)/sysctl(8), sensorsd(8), ntpd(8),
      systat(1), ports/sysutils/symon and 51 drivers as of
      2007-07-07.</p>

      <p>This GSoC2007 project is to port the underpinnings of this
      unified hardware monitoring interface to FreeBSD. Whilst it won't
      be possible to port all of the drivers due to architecture
      differences, we aim at porting all other parts of the framework
      and accompanying userland utilities.</p>

      <p>At this time, lm(4) at isa and some kernel api have already
      been ported. The next big step is to complete sysctl(3) glue code
      so that further work on porting userland utilities could be
      accomplished. Details about sysctl are being discussed on
      arch@.</p>
    </body>

    <help>
      <task>sysctl(3) glue code</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Porting Linux KVM to FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Fabio</given>

          <common>Checconi</common>
        </name>

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

      <person>
        <name>
          <given>Luigi</given>

          <common>Rizzo</common>
        </name>

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

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

    <body>
      <p>The Linux kernel-based Virtual Machine (KVM) is a mechanism to
      exploit the virtualization extensions present in some modern CPUs
      (e.g., Intel VT and AMD-V). Virtualization extensions let
      ordinary processes execute a subset of privileged instructions in
      a controlled way at near-native speed. This in turn may improve
      the performance of system emulators such as qemu, xen, vmware,
      vkernel, User Mode Linux (UML), etc.</p>

      <p>This project consists in porting to FreeBSD the Linux KVM,
      implemented as a loadable module, lkvm.ko. We use the approach in
      ports/devel/linux-kmod-compat to reuse the original Linux source
      code almost unmodified. We will also port a modified version of
      qemu which exploits the facilities made available by the Linux
      KVM to speed up emulation.</p>

      <p>The URL above links to progress report detailing the exact
      project goals, milestones reached, and commit log details.</p>

      <p>As of end of June 2007, we have mainly extended
      linux-kmod-compat to support the kernel API used by the Linux KVM
      code. The required functions have been implemented at various
      degrees, from simple stubs to fully functional ones. We have also
      imported the modified qemu and the libraries that are used to
      build the Linux KVM userspace client. In the second half of the
      SoC work we plan to complete the implementation of the kernel API
      and have a fully functional Linux KVM module, together with its
      client (qemu).</p>
    </body>
  </project>

  <project cat='soc'>
    <title>Multicast DNS and Service Discovery</title>

    <contact>
      <person>
        <name>
          <given>Fredrik</given>

          <common>Lindberg</common>
        </name>

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

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

    <body>
      <p>This project aims to create a multicast DNS daemon and service
      discovery utilities suitable for the base system. Multicast DNS
      is a part of Zero Configuration Networking (Zeroconf) and
      provides the ability to address hosts using DNS-like names
      without the need of an existing (unicast), managed DNS server.
      Work on the responder daemon is well underway and the only large
      missing piece of the puzzle is a way for local clients to do
      queries. The code can be found in the p4 branch
      projects/soc2007/fli-mdns_sd if anyone would like to give it a
      spin, even though it's incomplete. The project plan can be found
      on the wiki.</p>
    </body>
  </project>

  <project cat="soc">
    <title>FreeBSD-update front end</title>

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

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

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

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

    <body>
      <p>The project is split up with a front end to interact with the
      user and a back end to interact with freebsd-update. The back and
      front ends are able to communicate with each other using an XML
      protocol. The GUI is almost at the point it can take a command
      from the user and send it to the back end. The back end is able
      to detect when updates are ready.</p>
    </body>
  </project>

  <project cat='misc'>
    <title>EuroBSDcon 2007</title>

    <contact>
      <person>
        <name>
          <common>EuroBSDCon 2007 Organizing Committee</common>
        </name>

        <email>info@EuroBSDCon.dk</email>
      </person>
    </contact>

    <links>
      <url href="http://2007.EuroBSDCon.org/" />
    </links>

    <body>
      <p>The sixth EuroBSDCon will take place at Symbion in Copenhagen,
      Denmark on Friday the 14th and Saturday 15th of September
      2007.</p>

      <p>The programme is ready and online at the webpage. Registration
      is open. Details about tutorials and Legoland trip are ready too.
      
      <br />

      The keynote will be John Hartman: Real men's pipes</p>

      <p>If you share a room with friends at the hostel, then lodging
      is really inexpensive, and the lounge has high speed Internet
      access. Staying at the hostel is of course optional, and the area
      has several hotels.</p>

      <p>KD85.com and O'Reilly will each have a booth at the
      conference.</p>

      <p>We are still looking for more sponsors.</p>

      <p>A public IRC channel #eurobsdcon on EFnet has been created for
      discussion and questions about the conference.</p>
    </body>
  </project>

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

    <contact>
      <person>
        <name>
          <given>Matteo</given>

          <common>Riondato</common>
        </name>

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

      <person>
        <name>
          <given>FreeSBIE</given>

          <common>Staff</common>
        </name>

        <email>staff@freesbie.org</email>
      </person>

      <person>
        <name>
          <given>FreeSBIE</given>

          <common>ML</common>
        </name>

        <email>freesbie@gufi.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freesbie.org">FreeSBIE Website</url>

      <url href="http://liste.gufi.org/mailman/listinfo/freesbie">
      Freesbie ML Subscription</url>
    </links>

    <body>
      <p>After the success of FreeSBIE-2.0.1-RELEASE, development slew
      down a bit, but we have a big task for the summer: enable unionfs
      again and trying the new efficient memory filesystem, tmpfs.</p>

      <p>For all new ISO images we will be following RELENG_7, with the
      hope to release a stable image once 7.0-RELEASE have been
      released.</p>
    </body>

    <help>
      <task>Build and test an ISO image with
      FreeSBIE+unionfs+tmpfs.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Ports Collection infrastructure improvements</title>

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

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

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

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

          <common>Pantyukhin</common>
        </name>

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

    <links>
      <url href="http://wiki.freebsd.org/G%C3%A1borSoC2007">
      G&aacute;bor's SoC 2007 wiki page</url>
    </links>

    <body>
      <p>G&aacute;bor K&ouml;vesd&aacute;n is working on some
      improvements for the Ports Collection infrastructure. This year,
      he aimed to work on long-standing issues, which are tracked in
      GNATS, but we have not had a volunteer for recently. With the
      mentorship of Andrew Pantyukhin, he is also reimplementing the
      DESTDIR support for Ports Collection in a more practical way. The
      complete description and status of this project is available on
      G&aacute;bor's SoC 2007 Wiki page.</p>
    </body>

    <help>
      <task>Please see the Wiki page for the current status.</task>
    </help>
  </project>

  <project cat='misc'>
    <title>The Hungarian Documentation Project</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://www.freebsd.org/hu/docproj/hungarian.html">Info
      for volunteers</url>

      <url href="http://www.freebsd.org/hu/">Hungarian Webpages</url>

      <url
      href="http://www.freebsd.org/doc/hu_HU.ISO8859-2/articles/linux-comparison/">
      Latest translation</url>
    </links>

    <body>
      <p>We have added one translated article since the last status
      report about this project. The infrastructure is ready to support
      localized articles and books as well, we just lack of human
      resource. New volunteers are highly welcome! Please see the link
      below and contact G&aacute;bor if you are interested.</p>
    </body>

    <help>
      <task>Translate more articles and books.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>tarfs: A tar File System</title>

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

          <common>Anderson</common>
        </name>

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

    <links>
      <url href="http://www.googlebit.com/doku.php?id=tarfs">TarFS
      Wiki</url>
    </links>

    <body>
      <p>Tarfs is a simple tar file system implementation for
      FreeBSD.</p>

      <p>The current goals are:</p>

      <ul>
        <li>Support all standard read-only operations</li>

        <li>Support large tar files (several gb's)</li>

        <li>Use minimal memory</li>

        <li>Allow using tar file as a root file system</li>

        <li>Fast enough to actually use</li>
      </ul>

      <p>Here's the current state of things:</p>

      <ul>
        <li>Can mount most tar files</li>

        <li>Can do most operations (open,lookup,stat,readdir,etc)</li>

        <li>Supports large tar files (tested up to 2GB)</li>

        <li>Uses a relatively small amount of memory - proportional to
        number of files/dirs</li>
      </ul>
    </body>

    <help>
      <task>No `..' directory in root of mounted tar file system</task>

      <task>Locking issues regarding `..' in subdirs off root of
      fs</task>

      <task>No block/char special device support. Needed?</task>

      <task>Needs a directory hashing method</task>

      <task>More testing needed.</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</given>

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

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

    <links>
    </links>

    <body>
      <p>FAST_IPSEC has now replaced Kame IPsec as the IPsec stack in
      HEAD. This will be part of the 7.0 release. The merge happened in
      early July with George handling the kernel bits and Bjoern
      handling user space.</p>

      <p>The kernel option IPSEC is now the ONLY option for IPsec
      support in the FreeBSD kernel.</p>
    </body>

    <help>
      <task>Test test test!!!!</task>
    </help>
  </project>

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

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

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

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

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

      <url href="http://www.turbocat.net/~hselasky/usb4bsd">My USB
      Homepage</url>

      <url
      href="http://www.turbocat.net/~hselasky/usb4bsd/dev_new_usb.pdf">
      Code reference for the new USB stack and USB device drivers</url>
    </links>

    <body>
      <p>During the last three months there has been several changes to
      the USB stack. Here is a quick list of the most important
      changes:</p>

      <ol>
        <li>FULL speed isochronous devices over HIGH speed USB Hubs are
        now fully supported. Due to various reasons the maximum
        isochronous bandwidth has been limited to 6MBit/s. This limit
        is tunable.</li>

        <li>There is now full support for Linux USB device drivers
        through a Linux USB API emulation layer.</li>

        <li>Various cleanups and fixes.</li>
      </ol>

      <p>Markus Brueffer is still working on the USB HID parser and
      support. Nothing has been committed yet.</p>

      <p>If you want to test the new USB stack, checkout the USB
      perforce tree or download the SVN version of the USB driver from
      my USB homepage. At the moment the tarballs are a little out of
      date.</p>

      <p>Ideas and comments with regard to the new USB API are welcome
      at freebsd-usb@FreeBSD.org .</p>
    </body>
  </project>

  <project cat='kern'>
    <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>Gvirstor is a GEOM class which provides virtual storage
      capacity (something like virtual memory for storage devices).
      It's ready to be committed to HEAD (the plan is for it to get
      into 7.0-RELEASE).</p>
    </body>

    <help>
      <task>Any interested testers are welcome!</task>
    </help>
  </project>

  <project cat='soc'>
    <title>finstall</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/finstall" />
    </links>

    <body>
      <p>Project "finstall" aims to create a next-generation FreeBSD
      installer that will make use of the newest features present in
      the system. The project should yield something usable for
      7.0-RELEASE, but the intention is to keep it as a "second"
      installer system during 7.x, alongside sysinstall. In any case,
      sysinstall will be kept for architectures not supported by
      finstall (e.g. all except i386 and amd64).</p>
    </body>

    <help>
      <task>The work is progressing well and on plan. There's a small
      setback currently with X11 applications executing of a read-only
      file system (at least that's the currently recognizable
      symptom).</task>

      <task>Any interested testers are very much welcome!</task>
    </help>
  </project>

  <project cat='proj'>
    <title>HDTV Drivers (ATSC)</title>

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

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

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

    <links>
      <url
      href="http://perforce.freebsd.org/fileSearch.cgi?FSPC=%2F%2Fdepot%2Fuser%2Fjmg%2Fbktrau%2F...&amp;ignore=GO%21">
      bktrau Perforce source repository</url>

      <url
      href="http://perforce.freebsd.org/fileSearch.cgi?FSPC=%2F%2Fdepot%2Fuser%2Fjmg%2Fcxd%2F...&amp;ignore=GO%21">
      cxd Perforce source repository</url>
    </links>

    <body>
      <p>This entry was previously the Bt878 Audio Driver (aka
      FusionHDTV 5 Lite driver) announcement, but as work expanded
      slightly, it's a bit more generic now.</p>

      <p>A few bugs in bktrau has been fixed since January. If you have
      been running an earlier version, it is recommended to upgrade as
      the driver could panic. The driver works with multiple cards in
      the same machine (tested with two).</p>

      <p>
      <b>FusionHDTV 5 Lite</b>

      -- Due to lack of documentation from DViCO and LG, I have copied
      magic values from the Linux driver to get ATSC capturing
      working.</p>

      <p>
      <b>ATI HDTV Wonder</b>

      -- After years of trying to get into the ATI developer program,
      they have finally suspended it, so no support from ATI. I have
      started work on a driver, cxd, for the Conexant CX2388x based
      cards. The ATI HDTV Wonder uses ATI's own demodulator, and I was
      able to get it to tune, after cribbing from the Linux driver.
      When capturing, I get some valid data, but not all the data. Due
      to lack of support from ATI and linux-dvb the project has been
      put on indefinite hold.</p>

      <p>If someone has another CX2388x based card, it shouldn't be too
      hard to take the driver and get it working with a different
      tuner.</p>

      <p>A Python module is available for both drivers/cards, along w/
      a sample capture application using it. The module is now known to
      work well with threads so that tuning (expensive due to i2c
      ioctl's) can happen in another thread without causing program
      slow down. The module is working well with a custom PVR
      backend.</p>
    </body>

    <help>
      <task>Provide support for NTSC and FM tuning.</task>

      <task>Add support for other cards and tuners that use the Bt878
      chip.</task>

      <task>Add support for other cards and tuners that use the CX2388x
      chip.</task>
    </help>
  </project>

  <project cat='team'>
    <title>Problem Report Database</title>

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

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

        <email>bugmeister_at_FreeBSD_dot_org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freebsd.org/support.html#gnats">GNATS</url>

      <url href="http://people.freebsd.org/~bsd/prstats/">PR
      statistics</url>
    </links>

    <body>
      <p>Gavin Atkinson has joined the bugbuster team via getting a
      GNATS account on the FreeBSD cluster. He is following in the
      footsteps of Matteo Riondato, who later graduated to a full src
      commit bit. So far, he has helped close nearly 150 PRs, including
      many that had become stale. Welcome!</p>

      <p>Our short-term goal is to try to identify bugs that we might
      be easily able to fix before the 6.3/7.0 simultaneous release. So
      far, great progress has been made on ata- and usb-related
      PRs.</p>

      <p>The goal for the rest of this year is to generate more
      developer interest in fixing bugs. To do this, we are, first,
      trying to do more work on triaging PRs as they come in, to help
      flag ones that seem to be valid problems (especially if they
      include patches.) Secondly, we have started a new weekly periodic
      posting to the freebsd-bugbusters@FreeBSD.org mailing list, which
      is a short list of PRs that we feel are ready for committer
      action. This posting is automatically generated from a text-file
      list that we maintain.</p>

      <p>We are continuing to try to manage our community's
      expectations of what we can do with the incoming PRs. In
      particular, we are trying to discourage submissions of the form
      "I cannot get the XYZ function to work". In practice, these PRs
      are not worked on. Instead, we are now encouraging these postings
      to go to one of the mailing lists such as freebsd-questions@,
      freebsd-x11@, and so forth. The idea is to emphasize GNATS as a
      "Problem Report" method, rather than a "general FreeBSD support"
      method. I feel that, otherwise, we were creating a false
      expectation.</p>

      <p>The overall PR count has dropped to below 5000, despite the
      extra PRs still not cleared up from the ports freeze for the
      xorg7.2 import. Significant progress has been made on the i386,
      kern, and bin PRs, as well as PRs in the 'feedback' state. In
      addition, Warner Losh has made progress on closing many of the
      usb PRs.</p>
    </body>

    <help>
      <task>Please join us on the freebsd-bugbusters@ mailing list, or
      on #freebsd-bugbusters on EFNet, to help us triage PRs as they
      come in and also help us to work through the backlog, and help us
      to try to create a bugbusting "community".</task>
    </help>
  </project>

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

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

      <url href="http://portsmon.FreeBSD.org/index.html">FreeBSD ports
      monitoring system</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>The ports count is over 17,300. The PR count has been stable
      at around 800; we have not quite cleared up the backlog that
      showed up during the freeze to import xorg7.2.</p>

      <p>There have been 4 experimental runs on the build cluster, most
      notably resulting in some speedups for package registration. A
      further experimental run to genericize autotools handling is in
      progress.</p>

      <p>One of the most sweeping ports commits to happen in years was
      the upgrade of xorg from 6.9 to 7.2. This involved a complete
      rework of the internals of the port, as X.org itself has
      effectively pushed the responsibility for packaging to the OSes
      that incorporate it. The idea was to be able for them to update
      individual code (such as video drivers) without having to reroll
      the entire distribution. This commit caused us to have the
      longest period of preparation work, and actual tree lockdown,
      that I am aware of. The commit continues to be controversial,
      partly due to the fact that none of our port upgrade tools was up
      to the task of doing the upgrade without manual intervention.</p>

      <p>At the same time that xorg was upgraded, we moved the
      installation directory from the obsolete /usr/X11R6 to our
      default /usr/local. This further complicated the upgrade.</p>

      <p>There have been new releases of the ports tinderbox code, the
      portmaster update utility, and portupgrade.</p>

      <p>GNOME was updated to 2.18.2.</p>

      <p>We have added 7 new committers since the last report. We
      appreciate all the new help. However, a few committers have
      turned in their commit bits for safekeeping, due to lack of
      time.</p>

      <p>Unfortunately, Clement Laforet has also had to step down from
      portmgr due to lack of time. We thank him for his help so
      far.</p>

      <p>Erwin, Kris and Mark met up at BSDCan and reviewed all the
      portmgr-owned PRs. A large number were closed, or suspended
      pending more work from the submitter. After closing the PRs that
      were committed after the -exp builds, the number of portmgr owned
      PRs came down to an all time low of 48 from around 70. We hope to
      make further progress during the rest of the year.</p>
    </body>

    <help>
      <task>gcc4.2 has been imported to the base for 7.0.
      Unfortunately, this breaks a large number of ports. We need
      committer and maintainer help to get these in good shape for the
      release.</task>

      <task>Most of the remaining ports PRs are "existing port/PR
      assigned to committer". Although the maintainer-timeout policy is
      helping to keep the backlog down, we are going to need to do more
      to get the ports in the shape they really need to be in.</task>

      <task>Although we have added many maintainers, we still have many
      unmaintained ports. The packages on amd64 are lagging behind a
      bit; those on sparc64 require even more work.</task>
    </help>
  </project>

  <project cat='net'>
    <title>Network Stack Virtualization</title>

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

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

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

    <links>
      <url href="http://imunes.tel.fer.hr/virtnet/" />
    </links>

    <body>
      <p>The network stack virtualization project aims at extending the
      FreeBSD kernel to maintain multiple independent instances of
      networking state. This will allow for complete networking
      independence between jails on a system, including giving each
      jail its own firewall, virtual network interfaces, rate limiting,
      routing tables, and IPSEC configuration.</p>

      <p>I believe that the prototype, which is kept in sync with
      FreeBSD -CURRENT, is now sufficiently stable for testing. It
      virtualizes the basic INET and INET6 kernel structures and
      subsystems, including IPFW and PF firewalls, and more. In the
      next month I plan to have the IPSEC code fully virtualized, and
      refine and document the management APIs. The short-term goal is
      to deliver production-grade kernel support for virtualized
      networking for FreeBSD 7.0-RELEASE (as a snap-in kernel
      replacement), while continuing to keep the code in sync with
      -CURRENT for possible merging at a later date.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>mtund - Magic Tunnel Daemon</title>

    <contact>
      <person>
        <name>
          <given>Matus</given>

          <common>Harvan</common>
        </name>

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

    <links>
      <url href="http://wiki.freebsd.org/SuperTunnelDaemon">mtund wiki
      page</url>
    </links>

    <body>
      <p>IP can easily be tunneled over a plethora of network protocols
      at various layers, such as IP, ICMP, UDP, TCP, DNS, HTTP, SSH.
      While a direct connection may not always be possible due to a
      firewall, the IP packets could be encapsulated as payload in
      other protocols, which would get through. However, each such
      encapsulation requires the setup of a different program and the
      user has to manually probe different encapsulations to find out
      which of them works in a given environment.</p>

      <p>mtund is a tunneling daemon using run-time loadable plugins
      for the different encapsulations. It automagically selects the
      best encapsulation in each environment and fails over to another
      encapsulation in case the environment changes. There already is
      running code available, capable of tunneling via TCP and UDP with
      a working failover mechanism. As this is a Summer of Code
      project, rapid changes and addition of new features can be
      expected during the summer. Please see the wiki page for more
      details and up-to-date information.</p>

      <p>Note that the project originally started under the name of
      Super Tunnel Daemon, but was later renamed to mtund for Magic
      Tunnel Daemon.</p>
    </body>

    <help>
      <task>I am always happy to hear from others trying out the code
      and providing feedback, both positive and negative.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Fine grain thread locking</title>

    <contact>
      <person>
        <name>
          <given>Jeff</given>

          <common>Roberson</common>
        </name>

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

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

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

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

      <person>
        <name>
          <given>Kris</given>

          <common>Kennaway</common>
        </name>

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

    <links>
    </links>

    <body>
      <p>Over the past 6 months several developers undertook an effort
      to replace the global scheduler lock with a finer-grain interface
      modeled on the Solaris container lock approach. This
      significantly reduces contention on higher-end multiprocessor
      machines.</p>

      <p>This patch went into 7.0-CURRENT and has proven to be very
      stable. The last remaining bugs are in rusage and effect only
      process time accounting statistics.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>SCHED_SMP and SCHED_ULE</title>

    <contact>
      <person>
        <name>
          <given>Jeff</given>

          <common>Roberson</common>
        </name>

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

    <links>
      <url href="http://jeffr-tech.livejournal.com/">Benchmarks and
      SCHED_SMP discussion.</url>
    </links>

    <body>
      <p>SCHED_SMP is a fork of the ULE scheduler which makes use of
      the new fine grain scheduler locking in 7.0-CURRENT to
      significantly improve SMP performance on some workloads. It has
      improved and stronger affinity, smarter CPU load balancing,
      structural improvements and many sysctl tunables. This can be
      considered ULE 3.0. Discussions are ongoing as to whether this
      will go into 7.0 as SCHED_SMP or as SCHED_ULE in 7.0 or 7.1.</p>

      <p>SCHED_ULE has had many bugfixes and performance improvements
      over the 7.0 development cycle and should no longer be considered
      unstable or experimental. On most workloads it significantly
      outperforms SCHED_4BSD on SMP and even slightly outperforms it on
      UP. There are some pathlogical workloads which exhibit as much as
      a 5% performance penalty. Many thanks to Kris Kennaway and
      current users for bug reports and performance testing.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>Kernel contention reduction using mysql</title>

    <contact>
      <person>
        <name>
          <given>Jeff</given>

          <common>Roberson</common>
        </name>

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

    <links>
      <url href="http://jeffr-tech.livejournal.com/">mysql benchmarks
      and discussion.</url>
    </links>

    <body>
      <p>FreeBSD developers have been using mysql as a testbed to find
      kernel contention hotspots in the kernel. As a result of this we
      have seen a 5x performance improvement over 6.0 on 8way machines.
      Recent changes include finer locking in fcntl(), removing Giant
      from flock and fcntl F_SETLK. These changes will be available in
      7.0 and primarily improve write performance. Experimental changes
      to select() have also been discussed on arch@ that solve
      contention issues there however these will not be ready in the
      7.0 timeframe.</p>
    </body>
  </project>

  <project cat='vendor'>
    <title>PC-BSD</title>

    <contact>
      <person>
        <name>
          <given>Kris</given>

          <common>Moore</common>
        </name>

        <email>kris@pcbsd.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.pcbsd.org/">PC-BSD Homepage</url>
    </links>

    <body>
      <p>The last major updates are currently being made to PC-BSD 1.4,
      which will include KDE 3.5.7, Beryl, Flash, Intel Wireless,
      Nvidia Drivers and more! This release will also include new
      utilities to make running PC-BSD on the desktop easier than ever,
      including:</p>

      <ul>
        <li>Network Manager with WIFI Support</li>

        <li>Add / Remove Components</li>

        <li>Firewall Manager for PF</li>

        <li>Xorg Display setup wizard</li>
      </ul>

      <p>Once any final major issues are resolved, we will be issuing a
      public beta of PC-BSD 1.4 to ensure compatibility across a
      variety of platforms.</p>
    </body>
  </project>

  <project cat='misc'>
    <title>EuroBSDCon 2007 Developer Summit</title>

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

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

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

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

    <body>
      <p>The next developer summit will be different from the previous
      ones.</p>

      <p>Very different.</p>

      <p>Gone are the auditorium style seating, beamers, endless
      presentations and soggy sandwiches.</p>

      <p>Instead we head out to an old village school in the
      beautiful Danish countryside, we hang around all over the place,
      sleep in the old science room, cook our own food and hack the
      living daylights out of anything we care for.</p>

      <p>September 17th and 18th, right after EuroBSDcon2007 in
      Copenhagen. (Well, right after the optional trip to
      legoland...)</p>

      <p>Be there!</p>

      <p>PS: Yes, it's not uncivilized, there is a full speed ADSL and
      WLAN.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>http support for PXE</title>

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

          <common>Tarasov</common>
        </name>

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

    <links>
      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/taleks-pxe_http">
      Project repository.</url>

      <url href="http://wiki.freebsd.org/http_support_for_PXE">Project
      related Wiki-page.</url>
    </links>

    <body>
      <p>Main goal of project is to introduce code working in PXE
      preboot environment, able to download from web server via direct
      connection or http proxy and prepare booting of FreeBSD
      kernel.</p>

      <p>Already implemented, but haven't thoroughly tested: PXE
      wrappers core code, ARP, ICMP echo request/reply, sockets code
      similar to common sockets (UDP and TCP modules). On base of
      sockets: simple DHCP client, DNS client.</p>

      <p>Currently working on http client, TCP testing, kernel booting
      and documenting main concepts of project modules.</p>
    </body>

    <help>
      <task>Testing PXE API related code in different PXE
      implementations.</task>

      <task>Testing of implemented protocols.</task>
    </help>
  </project>

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

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

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

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

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

    <body>
      <p>Code freeze in preparation for FreeBSD 7.0 began on June 18th.
      There are several large projects still being finished up as well
      as some issues that resulted as "fallout" from the work done just
      before the code freeze started (e.g. things resulting from the
      GCC 4.2 import). A schedule for the 7.0 release has not been set
      yet but the hope is that the first BETA build will be done near
      the end of July with a "fairly normal" release cycle (a few BETA
      builds followed by two or three RCs, each separated by around two
      weeks).</p>

      <p>We are planning to release FreeBSD 6.3 around the same time as
      FreeBSD 7.0 is released so the release schedule for that will be
      set at the same point we set the release cycle for 7.0, hopefully
      late in July.</p>
    </body>
  </project>

  <project cat='net'>
    <title>10Gigabit Network Support</title>

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

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

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

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

          <common>Gallatin</common>
        </name>

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

      <person>
        <name>
          <given>Jack</given>

          <common>Vogel</common>
        </name>

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

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

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

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

    <body>
      <p>Support was added for two more 10gigabit network drivers and
      there were major advances on improving system performance over
      10g media.</p>

      <p>Kip Macy committed a new driver for the Chelsio adapters. The
      cxgb driver supports all current 10g adapters, as well as the new
      four-port gigabit model. The cxgb driver work was supported by
      Chelsio.</p>

      <p>Drew Gallatin made significant improvements to the Myricom 10g
      driver mxge. With these updates the driver does line rate
      transfers with less system overhead.</p>

      <p>Neterion contributed the nxge driver to support all their
      Xframe 10Gbe Server/Storage adapters. The initial driver import
      was done by Sam Leffler; a switch over to vendor support will
      happen soon.</p>

      <p>Jack Vogel is preparing a driver to support the latest Intel
      10g hardware devices. The new driver - ixgbe - will complement
      the existing ixgb driver that supports older Intel 10g cards.</p>

      <p>Kip and Drew worked with other folks on performance analysis
      and tuning. This work improved cpu affinity and reduced overhead
      for managing network resources. Work is also underway to define a
      common Large Receive Offlaod (LRO) infrastructure. LRO is
      analogous to TSO on the receive side enabling drivers to receive
      at near line rate with normal sized frames. This common code base
      will help replace driver-specific code.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>A GUI audit analyzer for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Dongmei</given>

          <common>Liu</common>
        </name>

        <email>ldm@ercist.iscas.ac.cn</email>
      </person>
    </contact>

    <links>
      <url href="">
      </url>
    </links>

    <body>
      <p>This project is due to provide a GUI audit log analysis tool
      for FreeBSD. Refer to ethereal/wireshark packet parsing engine
      and its framework to view and parse audit logs.</p>
    </body>

    <help>
      <task>Get a GUI framework using GTK2.0 include menu bar, toolbar,
      list view and tree view.</task>

      <task>Parse and display audit log in the trailer file in the list
      view and tree view.</task>

      <task>Online capture audit log and parse and display them in the
      list view and tree view</task>

      <task>Add the filter mechanism</task>

      <task>Add the statistic mechanism</task>

      <task>Remote audit log analysis mechanism</task>
    </help>
  </project>

  <project cat='soc'>
    <title>BSD Bintools project</title>

    <contact>
      <person>
        <name>
          <given>Kai</given>

          <common>Wang</common>
        </name>

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

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

    <body>
      <p>A basic implementation of ar(1) (include ranlib) was finished
      and available in the perforce repository. Currently it provides
      all the main functions an ar(1) should have and it is based on
      the libarchive and libelf library thus is expected to have a
      better and simpler structure than the GPL'ed version. The work
      left in this part of the project is to perform a elaborate test
      and add additional functions.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>Stack trace capture in PMCTools</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/PmcTools">PMCTools Wiki
      page.</url>
    </links>

    <body>
      <p>The kernel/hwpmc(4) bits of stack trace capture have been
      implemented and are available in Perforce under path
      '//depot/user/jkoshy/projects/pmc/...'. I'm currently enhancing
      pmcstat(8) to extract and summarize this information. Support by
      Google Inc. for this project is thankfully acknowledged.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>Linuxulator update</title>

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

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

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

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

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

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

    <links>
      <url href="http://wiki.freebsd.org/linux-soc2007">Linuxulator
      update 2007</url>
    </links>

    <body>
      <p>Just like last year I got the opportunity to work on updating
      the Linuxulator to Linux version 2.6. This year I work on
      finishing futexes, *at syscalls and epoll/inotify.</p>

      <p>I, cooperating with Konstantin Belousov, have managed to fix
      futexes to the state of passing the official futex testing
      program. The fix was committed and 7.0R will ship with correct
      futex implementation. Work is planned on removing Giant locking
      from futexes. This only needs some careful review and
      testing.</p>

      <p>These days I mostly focus on *at syscalls, the patch is almost
      finished for committing and I hope that it will make it into 7.0R.
      As a part of this work I implemented native FreeBSD syscalls as
      well. Watch arch mailing list as I post the patch there.</p>

      <p>I also finished writing my master thesis describing how the
      Linuxulator works and G&aacute;bor K&ouml;vesd&aacute;n is working
      on integrating it into official FreeBSD articles.</p>

      <p>No work has happened in the epoll/inotify area but I hope to
      work on it right after I finish the *at syscalls.h</p>
    </body>

    <help>
      <task>Finishing *at syscalls.</task>

      <task>Start the epoll/inotify work.</task>

      <task>Finish removal of Giant from futexes.</task>
    </help>
  </project>

  <project cat='soc'>
    <title>Security Regression Test</title>

    <contact>
      <person>
        <name>
          <given>Zhouyi</given>

          <common>Zhou</common>
        </name>

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

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

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

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

    <links>
      <url
      href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/zhouzhouyi%5fmactest%5fsoc">
      Perforce Repository.</url>
    </links>

    <body>
      <p>Security Regression Test is supported by the project of Google
      summer code 2007. The main objective of this stage is to test the
      correctness of FreeBSD Mandatory Access Control Framework
      including correctly passing the security label from userland to
      kernel and non-bypassibility of Mandatory Access Control
      Hooks.</p>

      <p>Work performed in the last month:</p>

      <ol>
        <li>Constructed a pair of pseudo ethernet drivers used for
        testing network related hooks. To avoid the packet go through
        the lo interface, the IP address in the packet is twisted in
        the driver.</li>

        <li>Constructed a framework for logging Mandatory Access
        Control hooks which is got called during a period of time. 
        <ul>
          <li>In kernel, every non-null label is got externalized into
          human readable string and recorded in a tail queue together
          with the name of hook that got called and possible flags or
          modes (etc. VREAD/VWRITE for mac_check_vnode_open hook).
          There is a thread much like audit subsystem's audit_worker
          logging the queue into a userspace file. The userland program
          use open, ioctl and close the /dev/mactest node to trigger
          and stop the logging. The logging file is truncated to zero
          every time the logging mechanism is triggered.</li>

          <li>In userland, a bison based parsing tool is used to parse
          the logged file and reconstruct the record chain which will
          be compared with testsuite supplied configuration file to
          examine if expected hooks is got called and the
          label/flags/modes are correct. c) The testsuite mainly
          follows src/tools/regression/fstest, modified to adapt to
          test Mandatory Access Control Framework and include tests for
          signals</li>
        </ul>
        </li>
      </ol>
    </body>

    <help>
      <task>The code is quick and dirty. For example, a call to vn_open
      without checking its return value which is not fault tolerance.
      The coding style also needs modifications.</task>

      <task>Although a test framework is completely constructed, the
      detailed test cases still need to be written, the test cases
      beside fstest and signal need to be add.</task>

      <task>Testing of audit subsystem has not begin.</task>

      <task>Other parts of Security Subsystem in FreeBSD also need
      concern.</task>
    </help>
  </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>Christian</given>

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

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

      <person>
        <email>trustedbsd-audit@TrustedBSD.org</email>
      </person>
    </contact>

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

    <body>
      <p>General cleanups in preparation for 7.0.</p>

      <p>Process audit state moved to the credential to allow it to be
      accessed lock-free in most cases, as well as allowing it to be
      used in asynchronous contexts.</p>

      <p>OpenBSM 1.0a14 has been imported, which: fixes IPv6 endian
      issues, makes OpenBSM gcc41 warnings clean, teaches
      audit_submit(3) about getaudit_addr(), adds zonename tokens;
      other changes since the existing CVS 1.0a12 release previously
      imported include man page improvements, XML printing support,
      better audit.log.5 documentation, additional 64-bit token types,
      and new audit event identifiers.</p>

      <p>MAC checks have been added so that MAC policies can control
      use of audit system calls.</p>

      <p>Additional system call arguments are now audited.</p>

      <p>Audit now provides a security.audit sysctl node in order to
      determine if audit support is compiled in; boot-time console
      printfs have been removed.</p>

      <p>"options AUDIT" is now in the 7-CURRENT GENERIC kernel, so
      AUDIT support will be available out of the box in 7.0 without a
      kernel recompile. Manually enabling audit support in rc.conf will
      still be required. With FreeBSD 7.0, AUDIT will be a fully
      supported, rather than experimental, feature.</p>
    </body>
  </project>

  <project cat='team'>
    <title>The FreeBSD Foundation</title>

    <contact>
      <person>
        <name>
          <given>Deb</given>

          <common>Goodkin</common>
        </name>

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

    <links>
      <url href="http://www.freebsdfoundation.org">The FreeBSD
      Foundation</url>
    </links>

    <body>
      <p>The FreeBSD Foundation ended Q2 raising over $116,000. We're
      almost half way to our goal of raising $250,000 this year! We
      continued our mission of supporting developer communication by
      helping FreeBSD developers attend BSDCan. We were also a sponsor
      of BSDCan and the developer summit. We are a sponsor of
      EuroBSDCon 2007 and are now accepting travel grant applications
      for this conference. Foundation board members met with
      representatives of companies that use or are thinking of using
      FreeBSD both in the bay area and Ottawa.</p>

      <p>The Foundation has negotiated a joint development agreement
      with Google, Inc. to sponsor FreeBSD developer Joseph Koshy to
      improve FreeBSD's HWPMC implementation, including adding
      stacktrace support, and a donation of SMP hardware for future SMP
      scalability work. We greatly appreciate Google's support for this
      project, which will facilitate performance measurement and
      optimization of both the FreeBSD operating system and
      applications running on it.</p>

      <p>To learn more about what we're doing, go to our website at 
      <a href="http://www.freebsdfoundation.org/">
      http://www.FreeBSDFoundation.org/</a>

      . Our July newsletter will be published soon to update you on how
      we've been supporting the project and community worldwide.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>TrustedBSD MAC Framework</title>

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

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

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

      <person>
        <email>trustedbsd-discuss@TrustedBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.TrustedBSD.org/mac.html">TrustedBSD MAC
      Page</url>
    </links>

    <body>
      <p>Cleanup of MAC Framework API/KPI layers: mac.h is now just the
      user and user&lt;-&gt;kernel API; mac_framework.h is the
      kernel&lt;-&gt;MAC Framework KPI, and mac_policy.h is the MAC
      Framework&lt;-&gt;MAC policy module KPI. Along similar lines,
      mac_label_get() and mac_label_set() accessor functions now allow
      policies to access label data without encoding struct label
      binary layout into policy modules, opening the door to more
      efficient layouts. struct label is now in mac_internal.h and used
      only inside the MAC Framework.</p>

      <p>General MAC policy cleanup, including removing no-op entry
      points and sysctls for some sample policies. mac_test(4) has been
      cleaned up significantly, and counters for all entry points
      added.</p>

      <p>A MAC check for UNIX domain socket connect has been added.</p>

      <p>MAC checks have been added so that MAC policies can control
      use of audit system calls.</p>

      <p>MAC checks that duplicate existing privileges but add no
      additional context have been removed (such as sysarch_ioperm,
      kld_unload, settime, and system_nfsd) -- checks aligned with
      privileges but that do provide additional context, such as
      additional arguments, have been kept.</p>

      <p>The Biba and LOMAC policies now implement priv(9) checks,
      differentiating between privileges that may compromise system
      integrity models, and those that don't.</p>

      <p>The essentially unused mnt_fslabel / mnt_label distinction has
      been eliminated by moving to a single mnt_label. No functional
      change to any policy.</p>

      <p>Several MAC-related interfaces have been modified to
      synchronize with the naming conventions present in the version of
      the MAC Framework adopted in Mac OS X Leopard; significant
      further changes are in the pipeline to complete this
      synchronization. While it will not be possible to reuse a policy
      between the two platforms without careful thinking and
      modification, this makes porting much easier.</p>
    </body>
  </project>

  <project cat='net'>
    <title>Multiprocessor Network Stack</title>

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

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

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

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

    <links>
      <url href="http://www.FreeBSD.org/projects/netperf/">Netperf
      Project Page</url>
    </links>

    <body>
      <p>The custom file descriptor array lock has been replaced with
      an optimized sx lock, resulting in 2x-4x improvement in MySQL
      transaction rates on 8-core MySQL benchmarks. This improvement is
      due to moving to shared locking for frequent fd lookup
      operations, as well as significant optimization of the case where
      the filedesc lock is highly contended (as occurs in the threaded
      MySQL server performing constant socket I/O).</p>

      <p>The custom socket buffer I/O serialization lock (sblock),
      previously created by interlocking SB_WANT and SB_LOCK flags with
      the socket buffer mutex, has been replaced with an optimized sx
      lock, leading to a 10% performance improvement in MySQL and
      PostgreSQL benchmarks on 8-core systems. As part of this change,
      sx locks now have interruptible sleep primitives to allow the
      SB_NOINTR flag to work properly.</p>

      <p>These changes also correct a long-standing bug in socket
      buffer lock contention and SB_NOWAIT reported by Isilon; a
      simpler patch has been merged to 6.x to fix this bug without
      merging loocking changes.</p>

      <p>TCP debugging is now properly synchronized using a new
      tcp_debug_mtx.</p>

      <p>UMA allocation counters are now used for pipes rather than
      custom atomic counters, resulting in lowered overhead for pipe
      allocation and free.</p>

      <p>Significant code cleanup, commenting, and in some cases
      MFC'ing, has taken place with respect to the network stack and
      synchronization. Additional DDB debugging commands for sockets of
      various sorts have been added, allowing listing of socket state
      from DDB without the use of GDB.</p>

      <p>Certain non-MPSAFE subsystems have been removed or will be
      removed from FreeBSD 7.0, including IPX over IP tunneling (not
      general IPX/SPX support, just the tunneling over IP), KAME IPSEC
      (FAST_IPSEC is MPSAFE and now now supports IPv6), i4b, netatm
      (two other ATM stacks are still present), and ng_h4. Some of
      these features will be reintroduced in FreeBSD 7.1, but by
      removing them now, we are able to remove the NET_NEEDS_GIANT
      compatibility infrastructure that significant complicates and
      obfuscates the socket and network stack code.</p>

      <p>Other measurement and optimization projects continue; however,
      the 7.0 locking/synchronization work for the network stack is
      essentially complete.</p>
    </body>

    <help>
      <task>New work to parallelize the netisr thread (netisr2) as well
      as distribute UDP and TCP processing over multiple CPUs by
      connection, rather than just by input source as in 7.0, was
      presented at BSDCan. This work will be targeted at the 8-CURRENT
      branch.</task>

      <task>Complete netatm and NET_NEEDS_GIANT removal for 7.0.</task>

      <task>Complete MPSAFE locking of mld6 and nd6 IPv6 subsystems,
      which currently run under a global lock.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>TrustedBSD priv(9)</title>

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

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

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

      <person>
        <email>trustedbsd-discuss@TrustedBSD.org</email>
      </person>
    </contact>

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

    <body>
      <p>Further reduction of suser(9) consumers in order to attempt to
      remove the suser(9) KPI for 7.0. This includes resource limits,
      System V IPC, PPP, netinet port reuse, the NFS server, and
      netatalk. Remove unnecessary or redundant privilege checks were
      possible. UFS-privileges that apply to other file systems have
      been renamed to VFS privileges.</p>

      <p>All suser_cred() flags and priv_check_cred() flags are no
      longer required, as SUSER_ALLOWJAIL and SUSER_RUID use are
      determined entirely inside kern_jail.c and kern_priv.c and
      selected based on the privilege number, not a calling context
      flag. All privileges are now consistently allowed or not allowed
      in jail, and consistently use the ruid or euid. We will leave the
      flags field there as it will likely be used for other things in
      the future.</p>

      <p>Documentation in suser(9) and priv(9) has been updated.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>Apple's MacBook on FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Rui</given>

          <common>Paulo</common>
        </name>

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

    <links>
      <url
      href="http://repoman.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2007/rpaulo%2dmacbook/">
      P4 repository</url>

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

    <body>
      <p>Apple's MacBook computers are nicely designed and have neat
      features that other laptops don't. While Mac OS X is a nice
      operating system, UNIX folks (like me) would prefer to run other
      operating systems like FreeBSD. This project aims to bring bug
      fixes and new drivers to FreeBSD that would help running this OS
      on this platform.</p>
    </body>

    <help>
      <task>Write drivers or fix issues for/with the touchpad,
      keyboard, remote control IR receiver, Bluetooth.</task>

      <task>Fix reboot, halt, suspend/resume issues.</task>
    </help>
  </project>

  <project cat='team'>
    <title>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, two security
      advisories have been issued concerning problems in the base
      system of FreeBSD; both of these problems were in "contributed"
      code maintained outside of FreeBSD. The FreeBSD Vulnerabilities
      and Exposures Markup Language (VuXML) document has continued to
      be updated; since the last status report, 35 new entries have
      been added, bringing the total up to 925.</p>

      <p>In order to improve handling of security issues in the FreeBSD
      Ports Collection a new "ports-security" team has been created to
      include ports committers who periodically help with fixing ports
      security issues and documenting them in the FreeBSD VuXML
      document. Committers who wish to help with this effort can
      contact simon@ for details.</p>

      <p>The following FreeBSD releases are supported by the FreeBSD
      Security Team: FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2. The
      respective End of Life dates of supported releases are listed on
      the web site; it is expected that of the upcoming releases,
      FreeBSD 6.3 will be supported for two years after release, while
      FreeBSD 7.0 will be supported for one year after release.</p>
    </body>
  </project>

  <project cat='soc'>
    <title>lockmgr rewriting</title>

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

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

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

      <person>
        <name>
          <given>Jeff</given>

          <common>Roberson</common>
        </name>

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

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

    <body>
      <p>The project consists in a rewriting of the lockmgr(9)
      interface on a lighter basis, using atomic instructions and
      direct usage of the sleepqueue interface. This should lead to a
      faster primitive, a saner interface and an higher maintainability
      of the code.</p>

      <p>So far, 3 newly files called kern/kern_lockng.c,
      sys/_lockmgrng.h and sys/lockmgrng.h have been created for the
      new primitive and an initial implementation has been committed
      into the perforce branch:
      //depot/user/attilio/attilio_lockmgr/...</p>

      <p>The implementation contains a good set of code intended to
      replace old lockmgr. Actually it only misses the support for lock
      draining that will be committed after an initial phase of testing
      and the inclusion of a better wake-up algorithm (which will
      simplify draining a lot and will improve performance on
      wakeup).</p>
    </body>

    <help>
      <task>Need some testing</task>
    </help>
  </project>

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

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

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

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

    <links>
      <url
      href="http://folk.ntnu.no/lulf/patches/freebsd/gvinum/soc2007">
      Patches of my SoC wo</url>

      <url href="http://blogs.freebsdish.org/lulf/">Weblog</url>

      <url href="http://wiki.freebsd.org/UlfLilleengen/SOC">
      Wikipage</url>
    </links>

    <body>
      <p>My previous status reports contained a lot of code that
      updated gvinum with the old vinum features.</p>

      <p>This year gvinum has been significantly rewritten. Lukas Ertl
      began rewriting the way gvinum is organized from using a multi
      consumer/provider model, to use a single consumer and provider,
      and having an event-system that first handles user-requests, and
      then runs normal I/O operations (Much like other GEOM classes).
      This makes the code easier to read, and perhaps there will be
      less bugs :)</p>

      <ol>
        <li>setstate on plexes and volumes.</li>

        <li>attach/detach command now works.</li>

        <li>concat/stripe/mirror commands. The previous code conflicted
        more than I expected with the new gvinum system, but it should
        work now.</li>

        <li>(Mounted) rebuilds possible.</li>

        <li>(Mounted) sync possible.</li>

        <li>Some refactoring of old code (Basically updating old code
        to use the new event system, and add some abstractions where
        possible)</li>
      </ol>

      <p>And of course, some time has gone to work out how things
      should be done, and to fix other bugs. I hope some of you are
      interested in trying this out (all the work has been in perforce
      so far), a patch can be found in the URL section. . This is a bit
      experimental, and although I've done much testing to hunt down
      bugs, there are most probably bugs left.</p>

      <p>I have other goals this summer as well. However, since some
      parts of gvinum was rewritten, I might not be able to do all of
      these, but growing is already working for the concatenated
      volumes (and also mirrored). I'd also like to implement growing
      for Raid5 arrays as well. Logging plexes would also be cool to
      have, but this is not really needed, since we have g_journal.
      Both these features will be addressed after I've made sure gvinum
      does all old vinum does, and also perhaps better. As I might have
      some extra time on my hands this summer, so I gladly accept
      suggestions on what else I might fix or implement "while I'm at
      it".</p>
    </body>

    <help>
      <task>Stability, stability, stability. I want gvinum to work
      really well. To accomplish that I have several test-machines I'm
      going to do different tests on. I sort of have a little test-plan
      in the working that I'll be using.</task>

      <task>A gvinumadmin tool that would make gvinum easier to use for
      unexperienced users. Perhaps integrate this into the installer.
      This is now probably something I'll do at the end, when hopefully
      everything works :) I might poke Ivan Voras a bit on this.</task>

      <task>Documenting gvinum and it's differences to vinum better. I
      take notes on where I need to document, so this is in
      progress.</task>

      <task>Implementing growing and shrinking of volumes.</task>

      <task>Implement logging plexes. Log all parity data being
      written.</task>
    </help>
  </project>

  <project cat='misc'>
    <title>libarchive/bsdtar</title>

    <contact>
      <person>
        <name>
          <given>Tim</given>

          <common>Kientzle</common>
        </name>

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

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

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

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

    <links>
      <url href="http://people.freebsd.org/~kientzle/libarchive/">
      Project page</url>
    </links>

    <body>
      <p>Both libarchive 2 and bsdtar 2 are now in -CURRENT and will be
      in 7.0. Libarchive 1.9 and bsdtar 1.9 should be in 6-STABLE in
      time for 6.3.</p>

      <p>libarchive 2 is much faster writing to disk than libarchive 1.
      It also supports new formats, has several minor API/ABI
      corrections, is more portable, and has many fewer bugs. Of
      special note is "libarchive_test", a new program that exercises
      much of the libarchive functionality; anyone interested in
      working on libarchive should become familiar with this test
      suite. bsdtar 2 is less ambitious, but does have a number of bug
      fixes and takes advantage of several new features in libarchive
      2.</p>

      <p>libarchive 1.9 is identical to libarchive 2 except it
      maintains the old API/ABI. Similarly, bsdtar 1.9 is nearly
      identical to bsdtar 2, lacking only a few features that would
      prevent it from being used with existing libarchive 1
      libraries.</p>
    </body>

    <help>
      <task>Tim Kientzle has started work on a libarchive-based cpio
      implementation that should be ready for inclusion with FreeBSD
      8.</task>

      <task>Volunteer needed: We want a libarchive-based pax to replace
      our out-of-date pax implementation.</task>

      <task>Volunteer needed: pkg_add should use libarchive instead of
      forking an external tar; this could eventually make it much
      faster.</task>

      <task>Volunteer(s) needed: libarchive should write more cpio
      variants (easy); libarchive should read and write mtree format
      (not difficult); libarchive should write GNUtar 1.0 format sparse
      tar entries (tricky); bsdtar should support
      --metadata=&lt;archive&gt; to read names and properties from one
      archive, with data from disk, to create a new archive (mtree
      support in libarchive would make this very useful); bsdtar should
      preserve sparseness when creating archives.</task>
    </help>
  </project>

  <project cat='proj'>
    <title>USB update</title>

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

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

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

    <links>
    </links>

    <body>
      <p>About 18 months ago, I started to remove the compatibility
      macros that we had in the USB stack. These macros made it very
      hard to read the code and to diagnose problems. They represented
      a barrier to entry for people reading and understanding the
      stack. In addition, many of them effectively hid bugs from all
      but the most intensive investigations of the code.</p>

      <p>I've removed almost all of the macros in the client drivers,
      and all instances of the macros in the core FreeBSD USB stack.
      This makes the drivers more readable, and a little more robust.
      During this process, I fixed a lot of little bugs that people had
      been tripping over, and some that people hadn't reported. I've
      added a boatload of new vendor and product ids to the drivers
      from user PRs as well as from OpenBSD/NetBSD drivers.</p>

      <p>I finished up this work so that the FreeBSD USB stack would be
      more maintainable during the RELENG_7 period of time. I plan on
      MFCing most of the changes I've made into RELENG_6 after they
      have been shaken out in current. There was only one API changes
      in this work, so this is doable, and makes sharing drivers
      between 6.x and 7.x much easier. At this stage, it is unclear how
      long RELENG_6 will be around, so I'm hoping this will make USB
      much better in 6.3 if that's the release people choose to
      run.</p>

      <p>I've shied away from many of the more complicated changes to
      the stack. There's work being done outside of the tree by Hans
      Petter Selasky (hps) to make these sorts of changes. There is
      much in his stack that's ready to be merged, and I hope to
      integrate from that work useful bits that can be merged without
      disruption to improve the FreeBSD USB stack.</p>

      <p>I'm also looking for other FreeBSD developers that can jump in
      and help. Nearly all of the improvements I've done by spending a
      few hours a week sorting through the PRs for extremely low
      hanging fruit. There's plenty of room for others to be involved
      as well in improving FreeBSD's USB stack, as well as chances for
      us to import the now-useful bits from the evolving hps USB stack,
      hopefully reducing the diffs between it and the present FreeBSD
      USB stack. In addition, I'm looking for someone to do similar
      device ID merges from DragonFlyBSD.</p>

      <p>Finally, I've embarked on a mission to try to merge all the
      BSD's usbdevs files. There's no reason to have separate ones.
      I've started to modify usbdevs(1) to read the
      src/sys/dev/usb/usbdevs file and report more verbose information
      that way. A merged usbdevs would be larger, and take up more
      memory in a USBVERBOSE kernel, so to mitigate that effect, I'm
      making changes to usbdevs(1).</p>
    </body>

    <help>
      <task>The biggest area of concern before the 7.0 release is to
      get the updated device lists into the manual pages. This task is
      too big for me to take on in addition to the work I'm doing in
      cleaning up.</task>

      <task>We need more people that are willing to help out on the
      'trivial' PRs that add IDs to the driver. In addition, we need
      people to periodically sync our driver lists with DragonFlyBSD,
      NetBSD, and OpenBSD drivers.</task>

      <task>Merging the other BSD's usbdevs tables would be very
      helpful.</task>

      <task>Writing a usbdevs parser for usbdevs(1) to use.</task>
    </help>
  </project>

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

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

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

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

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

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

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

    <body>
      <p>A major update of the 802.11 wireless support was committed.
      Changes include advanced station mode facilities such as
      background scanning and roaming, and support for 802.11n devices.
      In addition parts of the Atheros' SuperG protocol extensions were
      added so that wireless clients that communicate with
      Atheros-based access points can operate more effectively. The
      changes to the infrastructure are also important because they
      simplify future distribution of Virtual AP (VAP) support.</p>

      <p>This work represents the effort of many people including Kip
      Macy, Andrew Thompson, Sepherosa Ziehau, Max Laier, and Kevin Lo.
      Getting these changes into the tree now ensures they will be
      present for the lifetime of the 7.x branch.</p>

      <p>The scanning and SuperG work were supported by Atheros. The
      802.11n-related work was supported by Marvell.</p>
    </body>

    <help>
      <task>Please test your wireless networking, especially during the
      7.0 BETA and RC period.</task>
    </help>
  </project>

  <project cat='net'>
    <title>FreeBSD and Wake On Lan</title>

    <contact>
      <person>
        <name>
          <given>Stefan</given>

          <common>Sperling</common>
        </name>

        <email>stsp@stsp.name</email>
      </person>
    </contact>

    <links>
      <url href="http://stsp.name/wol/" />

      <url href="http://stsp.name/wol/README.txt" />

      <url
      href="http://www.freebsd.org/cgi/query-pr.cgi?pr=83807&amp;cat=kern" />
    </links>

    <body>
      <p>I have been working on making wake on lan (WOL) work with
      FreeBSD. Contrary to popular believe OS support is required for
      WOL to work properly. In particular network card drivers need to
      configure network cards for WOL during system shutdown, else the
      cards won't wake up. WOL is _not_ just a BIOS issue.</p>

      <p>This is work in progress. Currently the following
      cards/chipsets are supported:</p>

      <ul>
        <li>NatSemi DP83815 (if_sis)</li>

        <li>Via Rhine (if_vr, only VT6102 and up chips support
        WOL)</li>

        <li>Nvidia nForce (if_nve, 
        <b>needs testing</b>

        )</li>

        <li>3Com Etherlink XL and Fast Etherlink XL (if_xl, 
        <b>needs testing</b>

        , only 3c905B type adapters support WOL)</li>
      </ul>

      <p>I would be glad to get more feedback on my patch. I can add
      support for more chipsets but I need testers for hardware I don't
      have. I would appreciate access to data sheets for any NIC
      chipsets that are supported by FreeBSD and have WOL support.</p>

      <p>I would especially appreciate technical feedback on the patch,
      preferably by a committer who is willing to nitpick the patch to
      make it ready for inclusion in -CURRENT. I currently maintain the
      patch against RELENG_6_2 for my own use but I would port it to
      -CURRENT for inclusion.</p>
    </body>
  </project>

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

    <contact>
      <person>
        <name>
          <given>Rink</given>

          <common>Springer</common>
        </name>

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

    <links>
    </links>

    <body>
      <p>Work is well under way to finish Kip Macy's FreeBSD/xen port,
      and get it into a shape which is suitable for inclusion in
      7.0.</p>

      <p>Generally, the port is stable and performs quite well. The
      major bottleneck is the inability to work with GCC 4.2, this is
      the last major TODO before the work can be committed.</p>
    </body>

    <help>
      <task>Fix the port to correctly work with GCC 4.2.</task>

      <task>Port the Xen drivers to newbus.</task>

      <task>Test/fix PAE support.</task>

      <task>Start on amd64 support.</task>
    </help>
  </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>
    </links>

    <body>
      <p>pf in HEAD (soon to be FreeBSD 7.0) has been updated to
      OpenBSD 4.1 bringing in a couple of new features:</p>

      <ul>
        <li>ftp-proxy has been rewritten, and a tftp version,
        tftp-proxy, has been added</li>

        <li>pf(4) now supports Unicast Reverse Path Forwarding (uRPF)
        checks for simplified ingress filtering</li>

        <li>The pflog(4) interface is now clonable. pf(4) can log to
        multiple pflog interfaces now, each rule can specify which
        pflog interface to log to</li>

        <li>pflogd(8) can now be told which pflog interface to work
        with</li>

        <li>pfctl(8) can now expire table entries</li>

        <li>keep state is now the default for pf.conf(5) rules, as is
        the flags S/SA option on TCP connections. no state and flags
        any can be used to disable stateful filtering or TCP flags
        checking</li>

        <li>The pfctl(8) ruleset optimiser can be enabled in
        pf.conf(5)</li>

        <li>pf(4) anchors can now be loaded inline in the main
        pf.conf(5) and can be printed recursively</li>

        <li>Allow pf(4) rules inside anchors to have their counters
        reset, and make counter read &amp; reset an atomic
        operation</li>
      </ul>

      <p>Some patches that went into OpenBSD after 4.1 and improve
      performance significantly will be merged later.</p>

      <p>Work to support pf and netgraph interaction is underway and
      will be imported after 7.0. As all required ABI changes have been
      made during the update, we will be able to MFC this work for 7.1
      later on.</p>
    </body>
  </project>

  <project cat='vendor'>
    <title>FreeBSD and Coverity Prevent</title>

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

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

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

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

          <common>Maxwell</common>
        </name>

        <email>dmaxwell@coverity.com</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>FreeBSD's static analysis scans have been updated with a
      recent version of Coverity Prevent. Coverity is providing
      additional advice on configuration of the analysis to maximize
      the benefit from the tools.</p>

      <p>At BSDCan2007, Coverity provided FreeBSD with a license for an
      additional analysis tool called Extend, which allows writing
      custom FreeBSD specific code checkers. David Maxwell presented
      training material for interested FreeBSD developers. Some
      applications of custom checkers have been considered, and more
      results will be forthcoming as they are implemented and
      tested.</p>
    </body>
  </project>
</report>

