<?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>October - December</month>

    <year>2007</year>
  </date>

  <section>
    <title>Introduction</title>

    <p>This report covers FreeBSD related projects between October and
    December 2007. 
    <a href="http://2008.asiabsdcon.org/">AsiaBSDCon 2008</a>

    is approaching and will be held at the Tokyo University of Science in
    Tokyo, Japan on the 27th - 30th of March 2008. The FreeBSD Foundation
    has released a 
    <a
    href="http://www.freebsdfoundation.org/press/2007Dec-newsletter.shtml">
    Newsletter</a>

    detailing their activities over the past few months.</p>

    <p>FreeBSD 7.0 is nearing release and the 2nd Release Candidate is
    ready for testing and is available for 
    <a href="http://www.freebsd.org/where.html#helptest">download now</a>.</p>

    <p>Thanks to all the reporters for the excellent work! We hope you
    enjoy reading.</p>
  </section>

  <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>docs</name>

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

  <category>
    <name>bin</name>

    <description>Userland Programs</description>
  </category>

  <category>
    <name>ports</name>

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

  <category>
    <name>misc</name>

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

  <project cat='misc'>
    <title>Bug Busting</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://wiki.freebsd.org/BugBusting/Resources">BugBusting
      Resources</url>

      <url href="http://wiki.freebsd.org/Bugathons/January2008">January
      2008 Bugathon</url>
    </links>

    <body>
    <p>As a result of a posting on freebsd-current@ complaining about a
    communication gap between users and developers, there has been a
    great deal of new interest in working on bugbusting -- in particular,
    we brainstormed on ideas on how non-committers can help. The two main
    ideas that are being discussed are incoming bug triage (classifying,
    rating, and so forth), and working with users (helping users to work
    through problems that aren't classical Problem Reports.</p>

    <p>As a result of this, we held our first Bugathon in quite some time
    (on #freebsd-bugbusters on EFNet). Over 30 people participated. As a
    result of this, over 120 PRs were closed, and dozens more were put
    into the 'feedback' state. Most of these PRs were in the kern/ and
    bin/ categories, which are the two that need the most work. (The new
    arrival rate was over 40/day during this time, including ports, so
    there was a significant net decrease.)</p>

    <p>Several new wiki pages were created to support this effort, and
    finally capture a lot of the previous discussions from both the
    mailing list and the IRC channel. There are even more good ideas
    which Mark Linimon has promised to work up and investigate,
    including:</p>
    <ul>
      <li>a web page to show "last N days of PRs"</li>

      <li>some way for committers to only view PRs that have been in some
      way 'vetted' or 'confirmed'</li>

      <li>more publicity for what we've already got in place, and for
      what we intend to do next</li>

      <li>new categories, classifications, and states for PRs, that will
      better match our workflow</li>
    </ul>

    <p>Note: at this time we are not yet looking to replace GNATS. The
    idea right now is to see what we can learn about how our workflow
    does (and ought to) work, and experiment with some low-cost changes
    to get various people's reactions. Linimon's feeling is that any of
    these kinds of changes would carry over to a new system, if we were
    to change over.</p>

    <p>rwatson also created a wiki page to put down some thoughts about
    how to work on the various kernel problems that are reported.
    Although preliminary, this captures some expertise and puts it into a
    place where prospective volunteers can more easily find it.</p>

    <p>The overall PR count is back up to just under 5300. Although this
    is net increase from the previous report, there were long periods of
    src and ports freeze during this time, which creates a spike in the
    overall count. (src and ports both remain in slush during that time).
    The peak number was approaching 5500.</p>

    <p>Overall, we seem to have some momentum and new volunteers
    interested in working on user-reported problems. bugmeister is
    hopeful that we can capitalize on this and make some good progress in
    the rest of 2008.</p>
    </body>
  </project>

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

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

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

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

    <body>
      <p>A large number of bugs have been fixed in the FreeBSD "coda"
      kernel module over the past six months, and a man page has been
      added to describe the module. Many of these bugs were the result of
      the coda module failing to keep up with the many enhancements to
      FreeBSD VFS over the last few years. As a result of these fixes, it
      is now possible to use Coda with FreeBSD 7.x and 8.x without
      immediate panics, and possibly for an extended period. The new man
      page does clarify that Coda is an experimental distributed file
      system and not yet appropriate for production use on FreeBSD, but
      things are looking a lot better than they were.</p>
    </body>

  </project>

  <project cat='docs'>
    <title>The Spanish Documentation Project</title>

    <contact>
      <person>
        <name>
          <given>José Vicente</given>

          <common>Carrasco Vayá</common>
        </name>

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

      <person>
        <name>
          <given>Gábor</given>

          <common>Kövesdán</common>
        </name>

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

    <links>
      <url
      href="http://www.freebsd.org/doc/es_ES.ISO8859-1/articles/fdp-es/">
      Info for volunteers</url>
    </links>

    <body>
      <p>Since the last status report we have made a nice progress about
      the website translation. The structure of the translated sites is
      polished and we have brought a significant set of pages up-to-date.
      New pages with important content have also been translated. Apart
      from the good progress, there is a still a lot to do. Some pages
      are still seriously outdated and some important parts are
      missing.</p>

      <p>At the same time, we have added one new article translation and
      one is still awaiting review before being committed.</p>
    </body>

    <help>
      <task>Continue synchronizing the website with the English one and
      translate further important parts</task>

      <task>Synchronize the articles and the Handbook</task>

      <task>Add new translations</task>
    </help>
  </project>

  <project cat='docs'>
    <title>The Hungarian Documentation Project</title>

    <contact>
      <person>
        <name>
          <given>Gábor</given>

          <common>Kövesdán</common>
        </name>

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

      <person>
        <name>
          <given>Gábor</given>

          <common>Páli</common>
        </name>

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

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

      <url href="http://www.freebsd.org/doc/hu_HU.ISO8859-2/articles/">
      Hungarian articles</url>

      <url
      href="http://perforce.freebsd.org/changeList.cgi?FSPC=//depot/projects/docproj%5fhu/books/handbook/...%2b//depot/projects/docproj%5fhu/share/...">
      Perforce changelist</url>
    </links>

    <body>
      <p>We have added the translation of the FreeBSD Flyer and
      maintained the existing translations. A huge progress is being made
      to provide a Hungarian translation of the FreeBSD Handbook. Also,
      there is an ongoing effort to provide Hungarian release notes for
      the upcoming FreeBSD releases.</p>
    </body>

    <help>
    <task>Translate Handbook</task>

    <task>Add release notes for HEAD and RELENG_7</task>

    0</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/reasons/reasons.html">
      Change summary</url>
    </links>

    <body>
      <p>Thanks to support from Cisco Systems, Inc, the port of the
      DTrace dynamic tracing framework from OpenSolaris to FreeBSD is
      active again. A solution to the integration issues surrounding the
      CDDL and BSD licenses has been found. There is an entirely BSD
      licensed set of hooks/shims which are optionally compiled into the
      kernel. This option can be included in the GENERIC kernel and
      shipped without any CDDL patent encumberance. The CTF (Compact C
      Type Format) tools now work across all architectures enabled in a
      'make universe'. A BSD licensed DWARF library has been developed.
      The kernel DTrace support is limited to amd64 and i386 at the
      moment. It currently passes 822 of the tests in the DTrace Test
      Suite. It is expected that the initial commit to FreeBSD-CURRENT
      will occur within the next month after review. Refer to the change
      summary page for details of the proposed changes.</p>
    </body>

  </project>

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

    <contact>
      <person>
        <name>
          <given>Mike</given>

          <common>Makonnen</common>
        </name>

        <email>mtm@FreeBSD.Org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.freebsd.org/~mtm/fin.tar.bz2" />
    </links>

    <body>
      <p>The FreeBSD Installer project (FIN) is yet another attempt to
      replace the aging sysinstall(8). I am attempting to keep the best
      parts of sysinstall(8) and combine them with the framework provided
      by the BSDInstaller (bsdinstaller.org) to create an installation
      program for FreeBSD that is multi-lingual, supports multiple
      installation media, supports remote installation, and is easily
      extensible to other installation types (gui, cgi, etc). The current
      implementation will slice disks, install your choice of base
      distributions, and set hostname and root password.</p>
    </body>

    <help>
      <task>Setting date, time, and time zone information</task>

      <task>Choosing and installing packages</task>

      <task>Support for installation media other than IDE CD-Rom (HTTP,
      FTP, etc)</task>

      <task>Integration with devel/gettext</task>
    </help>
  </project>

  <project cat='kern'>
    <title>LVM geom class</title>

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

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

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

    <body>
      <p>glvm is a geom class which reads the metadata from a LVM2 (Linux
      volume manager) disk and creates a geom provider for each logical
      volume. An example is the logs lv on a volume group called vg0
      appearing as /dev/lvm/vg0-logs, this can be mounted as a disk.</p>

      <p>The code is working and will be posted for testing soon.</p>
    </body>
  </project>

  <project cat='bin'>
    <title>malloc(3)</title>

    <contact>
      <person>
        <name>
          <given>Jason</given>

          <common>Evans</common>
        </name>

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

    <body>
      <p>malloc(3) has been enhanced in several ways to reduce lock
      contention when multi-threaded programs concurrently use the
      malloc(3) functions. The primary enhancements are lazy deallocation
      and dynamic arena load balancing.</p>

      <p>Lazy deallocation is designed to reduce contention for programs
      that use the producer-consumer model, where a thread produces
      (allocates) objects, and a pool of worker threads consumes
      (deallocates) those objects. As a side benefit, lazy deallocation
      also substantially reduces lock contention if multiple unrelated
      threads are using the same arena.</p>

      <p>Allocation activity patterns can change throughout the lifetime
      of a program. Dynamic arena load balancing monitors arena lock
      contention and re-assigns threads to other arenas as necessary,
      thus smoothing out allocator performance.</p>

      <p>In order to monitor lock contention in support of arena load
      balancing, I had to switch to using pthreads mutexes. This all by
      itself smoothed out allocator performance under high load, since
      the internal libc "spinlocks" aren't really spinlocks, whereas
      malloc now spins for a bit before blocking.</p>

      <p>I plan to MFC these changes to RELENG_7, hopefully in time for
      the FreeBSD 7.1 release.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>FreeBSD/mips</title>

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

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

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

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

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

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

      <person>
        <name>
          <given>Ollivier</given>

          <common>Houchard</common>
        </name>

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

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

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

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

    <body>
      <p>FreeBSD/mips boots to multiuser using gxemul on the MALTA board
      with a 4Kc based CPU. The port is targeting MIPS32 and MIPS64
      release 1 and release 2 based systems. Work is underway to support
      multicore systems.</p>

      <p>Preliminary ports to adm 5120, the IDT RC32434, the Sentry 5,
      and a few other targets have started. These ports are in various
      stages of stability.</p>

      <p>Juniper Networks has donated a generic MIPS FreeBSD port. This
      port doesn't run on any real hardware, but contains the necessary
      parts to run on idealized MIPS hardware. The FreeBSD/mips workers
      have been merging the current base and the Juniper code into a
      unified base. In addition, Cavium Networks has donated code
      supporting their multicore mips64r2 platform. This code is also
      being merged into the tree and cleaned up as well. The merged code
      base presently is making it to the first (or maybe second) call to
      cpu_switch before dying. Active work is underway in this area.</p>
    </body>
  </project>

  <project cat='misc'>
    <title>FreeBSD Mirror Site Status</title>

    <contact>
      <person>
        <name>
          <given>Edwin</given>

          <common>Groothuis</common>
        </name>

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

    <links>
      <url href="http://www.mavetju.org/unix/ftp-stats.php" />
    </links>

    <body>
      <p>There are several websites already with overview of the FreeBSD
      FTP mirrror sites, but they all seem to have one problem: They are
      not manually updated with the list of sites. For example,
      http://mirrorlist.freebsd.org/FBSDsites.php, despite being hosted
      by an Australia, doesn't have the Australian mirrors on it, while
      http://people.freebsd.org/~kuriyama/mirrors/ doesn't tell you which
      files are available from there. The data on my page shows the
      availability of the ISO images on all FTP mirror sites. The list of
      FTP mirror sites is obtained from DNS by either doing a
      zone-transfer or by just trying the standard names. The first data
      block shows a quick overview of the availability of the ISO image
      directories per server, architecture and mirror site. The second
      data block shows a verbose availability of the contents of the ISO
      image directories per server.</p>
    </body>

    <help>
      <task>The next addition will be the availability of the pre-build
      packages.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Multi-IPv4/v6 jails</title>

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

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

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

    <links>
    </links>

    <body>
      <p>The multi-IPv4/v6 jails project was resumed in early January
      after previous work had been abandoned in 2006.</p>

      <p>As an alternate solution to full network stack virtualization,
      this work shall provide a lightweight solution for multi-IP
      virtualization. The changes are even more important because of the
      emerging demand for IPv6.</p>

      <p>The current status includes updated user space utilities. Kernel
      side has grown support for multiple IP addresses for both address
      families in jails, while the old kernel internal lookup/checking
      functions were kept and can be compiled in during the transition
      period limiting jails to one IP address. Additionally a show jails
      DDB command was added to ease debugging.</p>

      <p>As an auxiliary project the last suser(9) checks were replaced
      in netinet6/ to support optional raw IPv6 sockets with jails. The
      new priv(9) checks were committed to HEAD.</p>
    </body>

    <help>
      <task>Check for proper v4-mapped v6 address handling.</task>

      <task>Review/add SCTP jail checks.</task>

      <task>Think of enhanced lookups for jails with lots of IP addresses
      (preserving the "primary" IPv4 address).</task>

      <task>Regression tests and review.</task>
    </help>
  </project>

  <project cat='vendor'>
    <title>if_nxge -- Neterion Xframe 10GbE Server/Storage adapter
    driver</title>

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

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

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

    <body>
      <p>The if_nxge driver, contributed by Neterion, has been merged
      into FreeBSD 8-CURRENT and FreeBSD 7-STABLE, and will appear in
      FreeBSD 7.0.</p>

      <p>The nxge driver provides support for Neterion Xframe-I and
      Xframe-II adapters. The driver supports TCP Segmentation Offload
      (TSO/LSO), Large Receive Offload (LRO), Jumbo Frames (5 buffer
      mode), Header Separation (Rx 2 buffer mode), VLAN, and Promiscuous
      mode.</p>

      <p>For general information and support, please visit the Neterion
      support page http://www.neterion.com/support/support.html.</p>

      <p>The nxge driver supports Neterion Xframe 10 Gigabit Ethernet
      adapters listed in http://www.neterion.com/how/pricing.html.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>Performance Monitoring Project</title>

    <contact>
      <person>
        <name>
          <given>Erik</given>

          <common>Cederstrand</common>
        </name>

        <email>erik@cederstrand.dk</email>
      </person>
    </contact>

    <links>
      <url href="http://littlebit.dk:5000/">Temporary website
      location</url>
    </links>

    <body>
      <p>As part of my thesis, I've been working on a framework to
      monitor the performance of CURRENT over time. The project is now in
      a state where a server and a slave are producing benchmark results
      and publishing the results to a web page for testing. Already, the
      setup has detected regressions. Lots of improvements can be made,
      but it is already quite useful. Over the next month I'll be adding
      a few features, fixing bugs and writing documentation.</p>
    </body>

    <help>
      <task>Decide on a useful set of benchmarks</task>

      <task>Find a more permanent home for the database and
      webserver</task>

      <task>Go live</task>
    </help>
  </project>

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

    <contact>
      <person>
        <name>
          <given>Aryeh</given>

          <common>Friedman</common>
        </name>

        <email>aryeh.friedman@gmail.com</email>
      </person>

      <person>
        <name>
          <given>Alejandro</given>

          <common>Pulver</common>
        </name>

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

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

          <common>Southwell</common>
        </name>

        <email>david@vizion2000.net</email>
      </person>
    </contact>

    <links>
    </links>

    <body>
      <p>Completed initial requirements gathering. Selection of
      development tools complete. General internal design complete.</p>

      <p>Ports 2.0 goals are:</p>

      <ul>
        <li>Re-engineer/modernize the ports build process using graph
        theory and more flexible depends calculations.</li>

        <li>Better document ports 1.0 and 2.0</li>

        <li>Maintain 100% user level compatibility with ports 1.0</li>

        <li>After a long trial period replace ports 1.0 in the "base
        system"</li>
      </ul>
    </body>

    <help>
      <task>Create engine</task>

      <task>Combine ports 1.0 docs from porters guide and the handbook
      into a single guide</task>

      <task>Create a proof of concept by building xorg (including all
      dependanicies) under the new system</task>

      <task>Create mailing list and web site</task>
    </help>
  </project>

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

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

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

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

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

      <url
      href="http://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 continues to accelerate and is now over 18,000.
      The PR count, which had dipped to around 750 before the 6.3/7.0
      freeze, is now back up to about 1000, due to the fact that we
      remain in ports slush.</p>

      <p>Because of the freeze/slush, no experimental ports runs have
      been committed since the last report. Although 2 more -exp runs
      have been completed, we are waiting for 7.0R to commit them.</p>

      <p>Once 7.0R happens, a lot of chaos is going to happen in the
      Ports Collection. This has built up during the long release cycle.
      Get ready for the following changes, among others:</p>

      <ul>
        <li>upgrade of KDE to 4.0 (being tested)</li>

        <li>upgrade to gettext</li>

        <li>upgrade to libtool</li>

        <li>introduction of perl 5.10</li>

        <li>final removal of XFree86 (deprecated for quite some
        time)</li>

        <li>removal of other expired ports</li>
      </ul>

      <p>Most of the portmgr activity was related to the QA process for
      the releases. In addition, linimon spent quite some time trying to
      get the sparc64 ports into better shape, and sent out a request for
      more people to help test sparc64 ports. Some people have responded
      with offers for letting committers get accounts on their machines.</p>

      <p>Unfortunately during this time period, we became unable to build
      packages for ia64-7. As a result, we are not currently building
      packages for ia64 any more. If any one wants to step up to work on
      this architecture, let portmgr know.</p>

      <p>We are currently building packages for amd64-5, amd64-6,
      amd64-7, amd64-8, i386-5, i386-6, i386-7, i386-8, sparc64-6, and
      sparc64-7. Note, however, that RELENG_5 will reach the end of its
      supported life on May 31, and package builds for those 2 buildenvs will stop
      as of that date. (8 buildenvs * 18,000 ports should be enough to
      keep us busy.)</p>

      <p>Other than that, the packages are in the best shape that they
      have been in for some time. linimon continues to work on package
      analysis tools for portsmon.</p>

      <p>We have added 2 new committers since the last report.</p>
    </body>

    <help>
      <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 over
      4,000 unmaintained ports (see, for instance, the list on portsmon).
      We are always looking for dedicated volunteers to adopt at least a
      few unmaintained ports. As well, the packages on amd64 and sparc64
      lag behind i386, and we need more testers for those.</task>
    </help>
  </project>

  <project cat='bin'>
    <title>procstat(1)</title>

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

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

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

    <links>
    </links>

    <body>
      <p>A new command line tool, procstat(1), allows detailed inspection
      and printing of process properties, including file descriptors,
      threads, kernel thread stacks, credentials, and virtual memory
      mappings of processes. Several new sysctls have been added to the
      kernel in order to export this information cleanly, and the
      stack(9) facility has been enhanced to allow the capture of kernel
      stacks from threads other than curthread. None of these features
      depends on procfs, continuing the effort to remove a requirement
      for procfs in order to print process information, as well as adding
      new types of information not available with procfs. Kernel stack
      printing is particularly useful as it provides much more detailed
      information on why a thread is blocked in kernel beyond the useful
      but limited wmesg context provided to date. This is helpful in
      debugging both user process problems and kernel problems. procstat
      has been merged into FreeBSD 8-CURRENT, and will be merged to
      7-STABLE after FreeBSD 7.0 is released.</p>
    </body>

    <help>
      <task>Merge to RELENG_7.</task>

      <task>Add a mode to print process signal disposition.</task>
    </help>
  </project>

  <project cat='doc'>
    <title>FreeBSD Greek Documentation Team</title>

    <contact>
      <person>
        <name>
          <given>Giorgos</given>

          <common>Keramidas</common>
        </name>

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

    <links>
      <url href="http://hg.hellug.gr/freebsd/doc-el/">Online Hg
      repository of the translation team's work-in-progress changes</url>
    </links>

    <body>
      <p>The Greek doc translation team has grown significantly since we
      started the translations. Most of the Handbook has already been
      translated to Greek (and committed to the CVS tree), as a
      collaborative effort of Manolis Kiagias, Nikos Kokkalis, Panagiotis
      Kritikakos, Vaggelis Typaldos, Stylianos Sideridis and others.
      Manolis has started translating the FAQ too, and we also tagged
      most of the Greek documents with their original, English revision
      ID. There are also plans for a translation of 
      <em>www/en</em>

      , but these may have to be deferred until we find the time to
      complete the Handbook, which is our primary target right now.</p>
    </body>

    <help>
      <task>Finish the Handbook translation</task>

      <task>Carefully review the translated text</task>

      <task>Resync the rest of the SRCID tags with English file
      revisions</task>

      <task>Keep translating more parts of the FAQ</task>

      <task>Start updating the articles to the latest English versions
      too</task>

      <task>As time permits, start a www translation too</task>
    </help>
  </project>

  <project cat='kern'>
    <title>FreeBSD SMP network stack scalability</title>

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

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

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

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

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

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

    <links>
    </links>

    <body>
      <p>There are a variety of on-going projects relating to improving
      SMP scalability of the FreeBSD network stack post-7.0. These
      include:</p>

      <p>
        <em>Detailed profiling of application workloads such as BIND9,
        MySQL, PgSQL and Apache have been used to identify performance
        bottlenecks and to guide changes to the source code.</em>
      </p>

      <p>
      <em>rwlock(9) use for pcbinfo and inpcb locking</em>

      , allowing the acquisition of only read locks for pcbinfo and inpcb
      during UDP receive and transmit--this is highly desirable in order
      to improve BIND9 performance, which sends and receives from many
      threads at a time on a single UDP socket.</p>

      <p>
      <em>Breaking out pcbinfo into a series of parallel data
      structures</em>

      , where the particular pcbinfo instance is selected using a hash of
      the connection tuple (and where ambiguous cases are present in all
      instances). This would allow greatly reducing pcbinfo contention
      for parallel input cases, which are increasingly likely with
      multiple input queue network devices, such as the Chelsio cxgb
      10gbps driver.</p>

      <p>
      <em>Investigation of use opportunities for rmlock(9)</em>

      -- rmlocks provide very lightweight acquisition for read, but
      expensive acquisition for write, and may be an appropriate
      replacement for rwlocks where significantly more reads than writes
      take place -- such as for firewall rule list protection, pf hook
      registration, address lists, etc.</p>

      <p>
      <em>Weak connection affinity</em>

      , in which the effective affinity of a connection, determined by
      its hash/rss work assignment to a particular input queue by the
      network stack or network card, is tracked and exposed to user space
      so that work associated with that connection can be performed on or
      close to the CPU where the kernel will be processing input for the
      connection. Software work placement has been done using the 
      <em>netisr2</em>

      implementation, which creates per-CPU netisr threads and assigns
      work based on connection properties.</p>

      <p>There are also many other pieces of related work going on,
      especially relating to 10gbps network drivers, and workloads of
      particular interest include BIND9, MySQL, pgsql, Apache, and
      general TCP parallelism.</p>
    </body>
  </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, four security
      advisories have been issued concerning problems in the base system
      of FreeBSD; one of these problems was 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, 61 new entries have been
      added, bringing the total up to 1023. Many of these new VuXML
      entries were made by members of the "ports-security" team.</p>

      <p>The "ports-security" team is still looking for more committers
      who can 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, FreeBSD 6.2, and FreeBSD
      6.3. The respective End of Life dates of supported releases are
      listed on the web site; it is expected that the upcoming FreeBSD
      7.0 release will be supported for one year after its release.</p>
    </body>
  </project>

  <project cat='misc'>
    <title>Opensource Solutions '08</title>

    <contact>
      <person>
        <name>
          <given>Mathieu</given>

          <common>Arnold</common>
        </name>

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

      <person>
        <name>
          <given>Ollivier</given>

          <common>Robert</common>
        </name>

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

      <person>
        <name>
          <given>Thierry</given>

          <common>Thomas</common>
        </name>

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

      <person>
        <name>
          <given>Rodrigo</given>

          <common>Osorio</common>
        </name>

        <email>rodrigo@bebik.net</email>
      </person>
    </contact>

    <links>
      <url href="http://www.solutionslinux.fr/en/" />
    </links>

    <body>
      <p>Like every year for the past few years is held what in France is
      mostly called "Solutions Linux" in Paris La Défense. The exhibition
      will take place the 29, 30 and 31st of January in the CNIT.</p>

      <p>The interesting thing about this event is that 80% of the floor
      is taken by companies (IBM, Novell, Oracle), and the remaining 20%
      is given freely to associations and non-profit organizations, where
      you'll find many (if not most) french LUGs, *BSDs, most Linux
      distributions, Mozilla, OOo...</p>

      <p>This year, FreeBSD will once again have a booth, and we'll be
      showing what FreeBSD is, why it's the damn best OS out there. We'll
      also be distributing flyers and CD's for the whole three days</p>

      <p>Admission to the exhibitions is free, so if you ever happen to
      pass by, come and see us, we'll be at booth A39.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>TCP ECN</title>

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

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

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

    <links>
      <url
      href="http://p4web.freebsd.org/@md=d&amp;cd=//depot/projects/&amp;c=DN2@//depot/projects/tcpecn/?ac=83">
      Perforce repository</url>

      <url
      href="http://lists.freebsd.org/pipermail/freebsd-net/2007-November/016007.html">
      Mail discussion</url>

      <url href="http://people.freebsd.org/~rpaulo/tcp_ecn.diff">
      Patch</url>
    </links>

    <body>
      <p>Completed and tested. Awaiting review from other committers.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>TCP Reassembly Queue Optimization</title>

    <contact>
      <person>
        <name>
          <given>Andre</given>

          <common>Oppermann</common>
        </name>

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

    <links>
      <url
      href="http://perforce.freebsd.org/changeList.cgi?CMD=changes&amp;FSPC=//depot/projects/tcp_reass/...">
      Change log</url>

      <url
      href="http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/tcp_reass/netinet/tcp_reass.c">
      TCP reassembly queue source file</url>
    </links>

    <body>
      <p>The FreeBSD TCP reassembly queue system has reached its limits
      with today's high speed links over long distances and large socket
      buffers. The old code is almost unchanged compared to 4.4BSD
      and gets quite inefficient with large mbuf chains.</p>

      <p>The new code aggregates consecutive segments into blocks and
      inserts the blocks into a tail queue. The insertion points for a
      newly arrived segment are checked in order of their probability.
      This prevents full chain traversals and is very efficient.</p>

      <p>To prevent easy resource exhaustion attacks the effective mbuf
      usage is accounted for and limited by the size of socket buffer.
      This way the reassembly queue can't be abused with many holes among
      small segments.</p>

      <p>A further addition is the combination of received SACK block
      tracking with the reassembly queue. The reassembly queue now tracks
      all blocks of segments. This makes tracking it again for SACK
      unnecessary. Additionally the limitation to six SACK blocks is
      lifted and the size of the inpcb structure is reduced quite a
      bit.</p>

      <p>The new code is stable and in testing correctly handles the
      download of a full set of FreeBSD CDROM images and 180 ports
      distfiles from widely distributed sites around the world at 2%
      packet loss.</p>
    </body>

    <help>
      <task>Additional small performance and space optimizations.</task>

      <task>Extended testing with new ipfw tcptruncate option to chop up
      TCP segments and feed them with full and partial loss into
      reassembly.</task>

      <task>Full code review by other TCP developers.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Major TCP Code Cleanup and Rewrite</title>

    <contact>
      <person>
        <name>
          <given>Andre</given>

          <common>Oppermann</common>
        </name>

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

    <links>
      <url
      href="http://perforce.freebsd.org/changeList.cgi?CMD=changes&amp;FSPC=//depot/projects/tcp_new/...">
      Change log</url>

      <url
      href="http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/tcp_new/netinet/tcp_input.c">
      TCP input source code</url>
    </links>

    <body>
      <p>The FreeBSD TCP code has evolved a lot over time and many new
      features were added. However over time it got crufty, complex and
      hard to read and track. In some places functionality was moved away
      but the corresponding code in the main TCP functions was not or not
      fully removed.</p>

      <p>The main purpose of of the TCP code cleanup and rewrite is to
      make the code:</p>

      <ul>
        <li>Easily readable again;</li>

        <li>Easily trackable again;</li>

        <li>A lot simpler to maintain;</li>

        <li>Verifiably correct and RFC conforming;</li>

        <li>Easily extendable for new congestion control algorithms;</li>

        <li>Increase in performance.</li>
      </ul>

      <p>Quite a bit of code is already (re)written but a lot still
      remains to be done.</p>
    </body>

    <help>
      <task>Integration of code from private branch into public perforce
      repository.</task>

      <task>Completion of code and rewrite. Integration with pluggable
      congestion control algorithms.</task>

      <task>Full code behavior check against all TCP RFCs and drafts of
      upcoming RFCs.</task>

      <task>Extended testing and full code review by other TCP
      developers.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>DDB scripting, output capture, and textdumps</title>

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

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

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

    <links>
    </links>

    <body>
        <p>The kernel DDB facility has been enhanced to add several new
        features:</p>

        <p>
        <em>DDB scripting</em>
        allows the user to define a set of simple scripts from within the
        debugger or userspace using the new ddb(8) tool to automate
        debugging steps. Scripts can be automatically executed when the
        debugger is entered ("kdb.enter.panic", "kdb.enter.break", ...)
        or manually using the DDB "run" command.</p>

        <p>
        <em>DDB output capture</em>
        allows the user to request that the output of DDB be captured
        into a buffer for access from user space or to be written out in
        a textdump.</p>

        <p>
        <em>DDB textdumps</em>,
        a new dump format that writes out a tarball of text-based
        debugging information, such as the kernel message buffer, panic
        message, kernel configuration, kernel version, and DDB capture
        buffer to the swap partition, to be extracted via savecore(8).
        This provides a compact, portable, and kernel compile independent
        debugging package.</p>

        <p>Various interesting formulas for use are described in ddb(4)
        and textdump(4); the facilities are separable, so you can, for
        example, run a few DDB commands and capture their output, then
        write a regular dump and extract that output using kgdb, or you
        can do the same and write it out as a textdump. Likewise, scripts
        can be used to automate manual debugging, or implement textdumps
        by enabling output capture, running a series of commands, and
        forcing a textdump to be written before rebooting.</p>

        <p>Support for these facilities has been merged into 8-CURRENT,
        and will be merged to 7-STABLE after the release of FreeBSD
        7.0.</p>
    </body>

    <help>
      <task>Improve semantics of combining textdumps with
      KDB_UNATTENDED.</task>

      <task>Allow scripts to use the DDB "continue" command when the
      script has been started automatically as a result of a KDB enter
      event, such as "kdb.enter.sysctl" or "kdb.enter.break".</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>
        <name>
          <given>TrustedBSD Audit Mailing List</given>
        </name>

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

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

      <url href="http://www.TrustedBSD.org/openbsm.html">TrustedBSD
      OpenBSM home page</url>

      <url href="http://www.TrustedBSD.org/bsmtrace.html">BSMtrace home
      page</url>
    </links>

    <body>
      <p>The TrustedBSD Project was proud to release OpenBSM 1.0, the
      first production release of OpenBSM, which is shipped with FreeBSD
      6.3 and will ship with FreeBSD 7.0. This release represents largely
      polishing, bug fixing, and cleanup over the previous alpha release,
      but for FreeBSD 6.x introduced features such as XML audit trail
      printing, new token types, and new event identifiers.</p>

      <p>A variety of development work continues on audit, including
      initial work on OpenBSM 1.1 alpha, work on improving the
      performance and semantics of audit pipes, and the experimental
      bsmtrace host intrusion detection package.</p>
    </body>

    <help>
      <task>Improve performance for live intrusion detection by
      introducing additional buffering and multi-record copying for audit
      pipes.</task>

      <task>Improve flexibility for live intrusion detection and
      monitoring by adding finer-grained record matching support for
      audit pipes, such as by-pid and by-pid-tree.</task>

      <task>Introduce multi-host network support for experimental
      bsmtrace intrusion detection package, allowing central monitoring
      and alarms on live bsm traces from many hosts.</task>

      <task>Continue analysis of CC audit requirements to flesh out
      missing event sources, such as user admin tools that don't
      currently generate audit records.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>VM Overcommit</title>

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

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

        <email>kostikbel@gmail.com</email>
      </person>

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

          <common>Holm</common>
        </name>

        <email>peter@holm.cc</email>
      </person>
    </contact>

    <links>
      <url href="http://people.freebsd.org/~kib/overcommit">The project
      page</url>
    </links>

    <body>
      <p>The patch to account the possibly required swap space and limit
      it by total amount of configured swap or per-uid limit is revived,
      ported to the 8-CURRENT. Now it is intensively tested by Peter
      Holm. Please, give it a run in the diverse workloads. Your comments
      are welcome!</p>
    </body>
  </project>

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

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

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

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

    <links>
      <url href="http://www.fsmware.com/xenofreebsd/7.0/download/">A
      small file-backed disk and some sample configuration files can be
      found</url>
    </links>

    <body>
      <p>The port will only run as a guest (i.e. domU) right now, on
      i386/PAE platforms. Status:</p>
      <ul>
        <li>domU is self-hosting on 8-CURRENT (can compile world + kernel
          in a VM).</li>
        <li>Xen 3.0.3 and earlier are not supported.</li>
        <li>Device structure needs to be cleaned up, it's not conformant
          to newbus.</li>
        <li>SMP and amd64 are targeted for support by May for RELENG_6
          and RELENG_7.</li>
        <li>dom0 support is not currently on the roadmap.</li>
      </ul>
    </body>

    <help>
      <task>Substantial cleanup needed, talk with Kip Macy or Scott Long
      if you are interested in helping</task>
    </help>
  </project>
</report>

