<?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>August</month>

    <year>2001</year>
  </date>

  <cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
    <cvs:keyword name="freebsd">
      $FreeBSD$
    </cvs:keyword>
  </cvs:keywords>

  <section>
    <title>Introduction</title>

    <p>The FreeBSD Project made substantial progress in the month of
    August, 2001, both on continuing the development of the RELENG_4
    line (4.x-STABLE and 4.x-RELEASE), and on 5.0-CURRENT, the main
    development branch. During this month, the decision was made to
    push the release of 5.0-CURRENT back so that KSE (support for
    fine-grained user threads) could be completed in time for the
    release, rather than postponing that support for 6.0. As such, the
    lifespan of the RELENG_4 line will be extended, with new features
    continuing to be backported to that branch. 4.4-RELEASE went into
    final beta during this month, and will also be available
    shortly.</p>

    <p>This month's edition of the status report has been written with
    the assistance of Nik Clayton and Chris Costello.</p>
  </section>

  <section>
    <title>Future submissions</title>

    <p>For next month, the submission procedures remain the same:
    reports should be between one and two paragraphs long, sent by
    e-mail, and in a format approximately that of this month's
    submissions (Project, Contact, URL, and text). Reminders will be
    mailed to the hackers@FreeBSD.org and developers@FreeBSD.org
    mailing lists at least a week before the deadline; complete
    submission instructions may be found in those reminders.</p>

    <p>-- Robert Watson</p>
  </section>

  <project>
    <title>Fibre Channel Support</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

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

    <links>
      <url href="http://www.feral.com/isp.html" />
    </links>

    <body>
      <p>2 Gigabit support was integrated on 8/31/2001 (QLogic
      2300/2312 cards). Because of the author's shrinking time
      commitment for FreeBSD, the previously planned "next step" which
      would have been more complete new CAM Transport integration is
      now probably just the addition of an FC-IP adjunct (as this can
      benefit many platforms simultaneously).</p>
    </body>
  </project>

  <project>
    <title>SCSI Tape Support</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

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

    <body>
      <p>A major update to error handling was done on 8/28/2001 which
      should correct most of the EOM detection problems that have been
      around for a while. There are several things to fix. The
      principle thing to fix next is the establishment of a loader(8)
      mediated device quirks method.</p>
    </body>
  </project>

  <project>
    <title>CAM</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

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

      <person>
        <name>
          <given>Justin</given>

          <common>Gibbs</common>
        </name>

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

      <person>
        <name>
          <given>Kenneth</given>

          <common>Merry</common>
        </name>

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

    <body>
      <p>No change since last status. Some discussion amongst all of us
      occurred, but lack of time and commitment to FreeBSD has meant
      little has actually been committed to the tree. SMPng work will
      be left to those who seem to have a notion about what needs to be
      done.</p>
    </body>
  </project>

  <project>
    <title>Intel Gigabit Ethernet</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

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

    <body>
      <p>No new status to report. This driver will be worked on again
      soon and cleaned up to work better.</p>
    </body>
  </project>

  <project>
    <title>KSE</title>

    <contact>
      <person>
        <name>
          <given>Julian</given>

          <common>Elischer</common>
        </name>

        <email>julian@elischer.org</email>
      </person>

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

          <common>Wemm</common>
        </name>

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

      <person>
        <name>
          <given>Matt</given>

          <common>Dillon</common>
        </name>

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

    <body>
      <p>Work in adding supporting infrastructure to the kernel for KSE
      threading support has reached "milestone 2".</p>

      <p>Milestone 2 is where the kernel source consistently refers to
      its resources in terms of per-thread and per-process resources,
      in the way that it will need to when there are &gt; 1 threads per
      process, but the LOGICAL changes to such things as the scheduler,
      and fork and exit, have not yet been made to allow more than one
      thread to be created. (nor have new threading syscalls been added
      yet). This is an important milestone as it represents the last
      point where the kernel has only "mechanical" changes. To go
      further we must start adding new algorithms and functions.</p>

      <p>The kernel for milestone 2 is reliable and has no noticeable
      performance degradations when compared to a matching -current
      kernel. (the differences are less than the margin of error, so
      that sometimes the new kernel actually fractionally beats the
      unaltered kernel).</p>

      <p>We hope that by the time this is published, the KSE patches
      will have been committed. The Major effect for most developers
      will be only that the device driver interface requires a 'thread'
      pointer instead of a Proc pointer in the open, close and ioctl
      entrypoints.</p>

      <p>I'm sure there will be small teething problems but we are not
      expecting great problems at the commit.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD core-secretary</title>

    <contact>
      <person>
        <name>
          <given>Alan</given>

          <common>Clegg</common>
        </name>

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

      <person>
        <email>core-secretary@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The position of Core Secretary was filled by Alan Clegg
      &lt;abc@FreeBSD.org&gt; The first core-secretary report should be
      available the second week in September and will cover the issues
      discussed by core during August 2001.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD PAM</title>

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

          <common>Murray</common>
        </name>

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

    <body>
      <p>Development is continuing; pam_unix has gained the ability to
      change passwords, login(1) has had PAM made compulsory (and is
      going to have more PAM-capable features handed over to PAM).</p>
    </body>
  </project>

  <project>
    <title>Netgraph ATM</title>

    <contact>
      <person>
        <name>
          <given>Hartmut</given>

          <common>Brandt</common>
        </name>

        <email>brandt@fokus.gmd.de</email>
      </person>
    </contact>

    <body>
      <p>The ATM stack has been tested with a number of FreeBSD
      machines and a Marconi ATM switch and seems to be quite stable
      running CLIP. Multi port support for the native ATM API has been
      implemented but needs some testing.</p>
    </body>
  </project>

  <project>
    <title>PRFW - hooks for the FreeBSD kernel</title>

    <contact>
      <person>
        <name>
          <given>Evan</given>

          <common>Sarmiento</common>
        </name>

        <email>ems@open-root.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freesoftware.fsf.org/jailuser" />
    </links>

    <body>
      <p>PRFW is a set of hooks for the FreeBSD kernel. It allows users
      to insert code into system calls, for such purposes as creating
      extended security features. Last week, PRFW reached 0.1.0, with
      many bugfixes and cleaning. I urge anyone who is interested to
      please visit the site, join the mailing list. Also take a peek at
      lsm.immunix.org, the Linux hooks. It will be a good contrast.</p>
    </body>
  </project>

  <project>
    <title>CVSROOT script rewrite/tidy</title>

    <contact>
      <person>
        <name>
          <given>Josef</given>

          <common>Karthauser</common>
        </name>

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

    <body>
      <p>Work is still progressing to make all of the perl scripts run
      using perl's 'strict' mode, and to migrate all FreeBSD specific
      options into the configuration file (CVSROOT/cfg.pm). I'll be
      looking for help soon to write a guide on how to make use of
      these scripts for use in your own repository. Anyone interested
      in helping should contact me at the above email address.</p>
    </body>
  </project>

  <project>
    <title>PPP IPv6 Support</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>The software has been committed to -current and seems
      functional. Outstanding issues include dealing with IPV6CP events
      (linkup &amp; linkdown scripts) and allocating site-local and
      global addresses (currently, ``iface add'' is the only way to
      actually use the link).</p>
    </body>
  </project>

  <project>
    <title>Porting ppp to hurd &amp; linux</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>Status is unchanged since last month. Patches have been
      submitted to get ppp working under HURD, and mostly under Linux.
      There are GPL copyright problems that need to be addressed. Many
      conflicts are expected after the commit of IPv6 support in
      ppp.</p>
    </body>
  </project>

  <project>
    <title>pppoed</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>Making pppoed function in a production environment. All known
      problems have been fixed and committed.</p>
    </body>
  </project>

  <project>
    <title>pppoa</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>I looked at bringing PPPoA into the base system, but could not
      because of an overly restrictive distribution license on the
      Alcatel Speedtouch modem firmware. It has been committed as a
      port instead and is running live at a FreeBSD Services client
      site.</p>
    </body>
  </project>

  <project>
    <title>OLDCARD improvements</title>

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

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

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

    <body>
      <p>The OLDCARD improvements have been completed, except for a few
      edge cases for older laptops with CL-PD6729/30 chips and some pci
      bios issues. Some minor work will continue, but after 4.4R is
      released, only a few remaining bugs will be fixed before the
      author moves on to greener fields of NEWCARD development.</p>
    </body>
  </project>

  <project>
    <title>jpman project</title>

    <contact>
      <person>
        <name>
          <given>Kazuo</given>

          <common>Horikawa</common>
        </name>

        <email>horikawa@psinet.com</email>
      </person>

      <person>
        <email>man-jp@jp.FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.jp.FreeBSD.org/man-jp/" />
    </links>

    <body>
      <p>Targeting 4.4-RELEASE, one team has been translating newly
      MFC'ed section [125678] manpages. The other team has been
      updating section 3 since May and one third (1/3) is finished. The
      port ja-groff is updated to be groff-1.17.2 based, and now it has
      the same functionality as base system does. The port ja-man is
      updated to have the search capability under an architecture
      subdirectory, as base system does. The doc/ja_JP.eucJP/man
      hierarchy update (adding architecture subdirectories) is planned
      after 4.4-RELEASE.</p>
    </body>
  </project>

  <project>
    <title>ARM port</title>

    <contact>
      <person>
        <name>
          <given>Stephane</given>

          <common>Potvin</common>
        </name>

        <email>sepotvin@videotron.ca</email>
      </person>
    </contact>

    <links>
      <url href="http://pages.infinit.net/sepotvin/" />
    </links>

    <body>
      <p>Basic footbridge support is now functional and the kernel is
      now able to probe the pci bus. Access primitives for the bus are
      still missing so I can't attach any drivers yet.</p>
    </body>
  </project>

  <project>
    <title>SYN cache implementation for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

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

    <body>
      <p>The syncache implementation is completed, and currently under
      testing and review. The code should be committed to -current in
      the near future, and a patchset for -stable made available.</p>
    </body>
  </project>

  <project>
    <title>Compressed TCP state</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

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

    <body>
      <p>State information for TCP connections is primarily kept in the
      TCP/IP control blocks in the kernel. Not all of the TCP states
      make use of the entire structure, and significant memory savings
      can be had by using a cut-down version of the state in some
      cases. The first phase of this project will address connections
      that are in the TIME_WAIT state by moving them into a smaller
      structure.</p>

      <p>This project has completed the initial research and rough
      design phases, with actual code development starting
      immediately.</p>
    </body>
  </project>

  <project>
    <title>Network SMP locking</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

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

    <body>
      <p>For 5.0, the goal is for the network stack to run without the
      Giant lock. Initial development in this area may focus on
      partitioning the code and data structures into distinct areas of
      responsibilities. A first pass of locking may involve using a
      several smaller mini-giant code locks in order to reduce the
      problem to a manageable size.</p>

      <p>Progress for this month includes the creation of a perforce
      repository to officially track the locking changes, and the
      initial submission of locks for the &amp;ifnet list. Some code
      cleanup has also been done to the main tree in order to better
      support future locking additions.</p>
    </body>
  </project>

  <project>
    <title>Network device nodes</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

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

    <body>
      <p>Currently, all network devices (fxp0, lo0, etc) exist in their
      own namespace, and are accessed through a socket interface. This
      project creates device nodes in /dev for network devices, and
      allows control and access in that fashion.</p>

      <p>This is experimental work, and suggestions for APIs and
      functionality are strongly encouraged and welcomed. In is not
      clear whether it will be possible (or desirable) to provide the
      exact same set of operations that can be done through the socket
      interface.</p>

      <p>Benefits of approach include the fact that a kqueue filter can
      be attached to a network device for monitoring purposes. Initial
      code exists to send a kq event whenever the network link status
      changes. Other benefits may include better access control by
      using filesystem ACLs to control access to the device.</p>
    </body>
  </project>

  <project>
    <title>RELNOTESng</title>

    <contact>
      <person>
        <name>
          <given>Bruce</given>

          <common>Mah</common>
        </name>

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

    <links>
      <url href="http://people.FreeBSD.org/~bmah/relnotes/" />
    </links>

    <body>
      <p>RELNOTESng, the DocBook-ified set of release documentation
      files, has been merged to the RELENG_4 branch. 4.4-RELEASE will
      be the first release of FreeBSD with the new-style release notes,
      hardware list, etc. Some of these documents are being translated
      by the Japanese and Russian translation teams.</p>

      <p>Snapshots of RELNOTESng for CURRENT and 4-STABLE in HTML,
      text, and PDF are available at the above URL and are updated
      irregularly but frequently. Dima Dorfman &lt;dd@FreeBSD.org&gt;
      and Nik Clayton &lt;nik@FreeBSD.org&gt; have been working to have
      automatically-generated snapshots on the main FreeBSD web
      site.</p>

      <p>On my TODO list: 1) Resynchronize the FreeBSD installation
      document with the installation chapter in the Handbook. 2) Update
      the hardware lists (with particular emphasis on PCCARD and USB
      devices). 3) Update the infrastructure to allow the
      architecture-dependent parts of RELNOTESng to scale to more
      hardware platforms.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD/sparc64 port</title>

    <contact>
      <person>
        <name>
          <given>Jake</given>

          <common>Burkholder</common>
        </name>

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

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

          <common>Moestl</common>
        </name>

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

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

          <common>Drehmel</common>
        </name>

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

    <body>
      <p>Sparc64 development is still continuing rapidly and we're
      making some excellent progress. Of note, some problems with the
      way the pmap module implements copy-on-write mappings have been
      fixed and fork() now works as expected, support for signals has
      been added, and the port has been updated for KSE in the perforce
      repository. Thomas Moestl has begun work on pci bus support, and
      a basic nexus bus for sparc64 has been written. The driver for
      the Sun `Psycho' and `Sabre' UPA-to-PCI bridges and associated
      code has been ported from NetBSD (the Sabre is the on-chip
      version found in the UltraSparc IIi and IIe). PCI configuration,
      I/O and memory space accesses do already work, as well as
      interrupt assignment and delivery for devices attached directly
      to the bridge, and the first PCI device drivers can attach and
      seem to work mostly. Interrupt routing and busdma support still
      need much work.</p>
    </body>
  </project>

  <project>
    <title>Documentation Project</title>

    <contact>
      <person>
        <name>
          <given>Nik</given>

          <common>Clayton</common>
        </name>

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

      <person>
        <name>
          <common>Documentation Project</common>
        </name>

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

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

      <url href="http://www.FreeBSD.org/docproj/index.html" />
    </links>

    <body>
      <p>The Handbook has been the main focus of activity this month.
      Due to go to the printers on the 15th a vast amount of new
      content has been submitted and committed. This includes a
      complete rewrite of the "Installing FreeBSD", which massively
      expands the amount of information available to people new to
      FreeBSD. It even includes screenshots.</p>

      <p>
        <a
        href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html">
        http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html</a>
      </p>

      <p>Comments, and contributions are, of course, welcome.</p>
    </body>
  </project>

  <project>
    <title>IP Multicast Routing support</title>

    <contact>
      <person>
        <name>
          <given>Bill</given>

          <common>Fenner</common>
        </name>

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

    <body>
      <p>FreeBSD's IP Multicast Routing support was recently updated in
      several ways. One big change is that it's now able to be loaded
      as a KLD instead of statically compiled into the kernel; this is
      especially useful for experimentation or updating of an existing
      system. It also now coexists nicely with the kernel IP
      encapsulation infrastructure, so that multicast tunnels can
      better coexist with MobileIP, certain IPSec tunnels and generic
      IPv4-in-IPv4 tunnels.</p>
    </body>
  </project>

  <project>
    <title>Mbuf SMPng allocator</title>

    <contact>
      <person>
        <name>
          <given>Bosko</given>

          <common>Milekic</common>
        </name>

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

    <links>
      <url href="http://people.FreeBSD.org/~bmilekic/code/mb_slab/" />
    </links>

    <body>
      <p>The allocator appears to be stable. Mbtypes statistics have
      been re-activated thanks, in part, to Jiangyi Liu
      &lt;jyliu@163.net&gt; although the diff has not yet been
      committed (I'm just in the process of cleaning it up a little and
      final testing). More work to come: cleanups, follow TODO from the
      original commit, and perhaps an eventual generalization of the
      allocator for various network-related allocations (in a more
      distant future).</p>
    </body>
  </project>

  <project>
    <title>RAIDframe for FreeBSD</title>

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

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

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

    <links>
      <url href="http://people.FreeBSD.org/~scottl/rf" />
    </links>

    <body>
      <p>After two months of little progress, RAIDframe work is gearing
      up again. The port to -stable has some known bugs but is fairly
      stable. The port to -current was recently completed and patches
      will be released soon. RAIDframe is a multi-platform RAID
      subsystem designed at CMU. This is a port of the NetBSD version
      by Greg Oster.</p>
    </body>
  </project>

  <project>
    <title>aac driver</title>

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

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

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

    <links>
      <url href="http://people.FreeBSD.org/~scottl/aac" />
    </links>

    <body>
      <p>The aac driver has been given a lot of attention lately and is
      now nearly feature complete. Changes include crashdump support,
      correct handling of controller initiated commands, and more
      complete management interface support. The Linux RAID management
      tool available from Dell and HP now fully works; a FreeBSD native
      version of the tool is also in the works. These changes have been
      checked into -current, and will appear in -stable once 4.4 has
      been released.</p>
    </body>
  </project>

  <project>
    <title>Problem Reports</title>

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

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

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

    <links>
      <url href="http://phk.freebsd.dk/Gnats/" />
    </links>

    <body>
      <p>We are making some progress, we are now down to 2170 open PR's
      down from an all time high of 3270 just 3 months ago. The aim is
      still to get rid of all the dead-wood in the PR database so only
      relevant PRs in the database. A big thanks from me to the people
      who have made this happen!</p>
    </body>
  </project>

  <project>
    <title>network device cloning</title>

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

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

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

    <body>
      <p>Support for cloning vlan devices via ifconfig has been
      committed to -current and will be MFC'd after further testing.
      Additionally, Maksim Yevmenkin submitted code to allow cloning of
      tap and vmnet devices on devfs systems. Code for faith and stf
      should be committed shortly.</p>
    </body>
  </project>

  <project>
    <title>ia64 Port</title>

    <contact>
      <person>
        <name>
          <given>Doug</given>

          <common>Rabson</common>
        </name>

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

    <body>
      <p>Current status is that the ia64 kernel builds and runs in a
      simulator environment up to single user mode and has been tested
      lightly in that environment. My current focus is on completing
      the ia64 loader so that I can start to get kernels working on the
      real hardware. The loader is coming along well and I expect to be
      able to load kernels (but not necessary execute them) soon.</p>
    </body>
  </project>

  <project>
    <title>libh Project</title>

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

          <common>Langer</common>
        </name>

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

      <person>
        <name>
          <given>Nathan</given>

          <common>Ahistrom</common>
        </name>

        <email>nra@FreeBSd.org</email>
      </person>
    </contact>

    <body>
      <p>I have access to the libh CVS repo again and am testing a new,
      OBJDIR capable build structure at the moment. Done that, I'm
      going to continue testing the package library and implement the
      missing functionality. Currently, import of libh into the base
      system is under discussion (arch mailinglist). Now that
      5.0-RELEASE has been shifted, I want 5.0 ship with a libh
      installer and package system. We can really need people who are
      good in C++, are able to understand what the current
      implementation does and also feel that working on libh is fun and
      thus are willing to help.</p>
    </body>
  </project>

  <project>
    <title>GNOME Desktop for FreeBSD</title>

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

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

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

      <person>
        <name>
          <common>FreeBSD GNOME Team</common>
        </name>

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

    <body>
      <p>Getting GNOME Fifth-Toe metaport ready for 4.4-RELEASE was the
      main focus of activity this month. In the process many components
      were updated, many bugs were tracked down and solved, which
      allowed to make this 97-component meta-package building and
      working properly.</p>

      <p>Next month the project will be focused on organizing work of
      the FreeBSD GNOME Team as well as on attempts to increase amount
      of people participating in the team (anybody who is willing to
      participate is welcome to drop a note to gnome@FreeBSD with a
      short explanation of how he/she could help).</p>
    </body>
  </project>

  <project>
    <title>fbsd-nvdriver</title>

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

          <common>Greenwald</common>
        </name>

        <email>erik@floatingmind.com</email>
      </person>

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

          <common>Willson</common>
        </name>

        <email>siigorny@linuxsveeden.borkborkbork</email>
      </person>
    </contact>

    <links>
      <url href="http://fbsd-nvdriver.sourceforge.net" />
    </links>

    <body>
      <p>NVIDIA Corporation releases Linux drivers by using a
      combination of binary object files and source (under a
      constrictive license). The FreeBSD NVIDIA driver project aimed to
      completely replace the source component of the driver using code
      targeting FreeBSD 4.3 and released under the BSD license. The
      binary module provided is supposedly the same module used on
      Windows, BeOS, and OS/2, so it should be portable between
      different i80x86 based OS's.</p>

      <p>The project is currently on indefinite hold. Our contact at
      NVIDIA seemed enthusiastic about the project, and was fairly
      quick about returning email, but when we discovered issues that
      prevented porting without changes to the binary component or
      error codes we needed deciphered, Nick (the contact) said he'd
      look into it and never got back. The first major problem was the
      ioctl interface, the NVIDIA driver passes a pointer and depends
      on the kernel side to copyout the right amount, where FreeBSD
      expect the parameters to be correct and the copyout is performed
      by the subsystem. This was worked around using Dave Rufinos
      "ioctl tunnel" idea. After that, we found that X refused to load
      and traced it down to an ioctl defined in the binary component
      erroring. We cannot tell what that ioctl is, were told that we
      could not sign an NDA for source to that component, and have been
      waiting a month for Nick to "look into it". Therefore progress is
      impossible (without breaking the license) and we believe that the
      flaws make the driver unportable to any *nix other than
      Linux.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD Release Engineering</title>

    <contact>
      <person>
        <name>
          <common>FreeBSD Release Engineer Team</common>
        </name>

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

    <body>
      <p>The FreeBSD release engineering process for FreeBSD 4.4
      started to ramp up around August 1st when the "code slush" took
      affect. During this time all commits to the RELENG_4 branch were
      reviewed by re@FreeBSD.org (over 250 code snippets had to be
      reviewed). After the first release candidate on August 15th, all
      submissions were scrutinized under a more strict potential risk
      vs benefit curve. The best way to help get involved with the
      release engineering process is to simply follow the low volume
      freebsd-qa mailing list, help out with the neverending supply of
      PRs related to our installation tools (sysinstall), or to work on
      a possible next-generation replacement for our installation
      technology, such as the libh or OpenPackages projects.</p>

      <p>Many companies donated equipment, network access, or paychecks
      to finance these activities. Including Compaq, Yahoo!, Wind River
      Systems, and many more.</p>
    </body>
  </project>

  <project>
    <title>Improved TCP Initial Sequence Numbers</title>

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

          <common>Silbersack</common>
        </name>

        <email>silby@silby.com</email>
      </person>
    </contact>

    <body>
      <p>In mid March, 2001, Tim Newsham of Guardent identified an
      attack possible against the initial sequence number generation
      scheme of FreeBSD (and other OSes.) In order to guard against
      this threat, a randomized sequence number generation scheme was
      ported over from OpenBSD and included in 4.3-release.
      Unfortunately, non-monotonic generation was found to cause major
      problems with applications which initiate continuous, rapid
      connections to a single host.</p>

      <p>In order to restore proper operation under such circumstances
      while still providing strong resistance against sequence number
      prediction, FreeBSD 4.4 uses the algorithm specified in RFC 1948.
      This algorithm hashes together host and port information with a
      piece of secret data to generate a unique sequence number space
      for each connection. As a result, outgoing initial sequence
      numbers are again monotonic, but also unguessable by an
      attacker.</p>
    </body>
  </project>

  <project>
    <title>LOMAC</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Feldman</common>
        </name>

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

    <body>
      <p>The port of LOMAC to FreeBSD is progressing well, and already
      has a very high level of stability (no known outstanding bugs!).
      Aspects which have already been implemented include a stacking
      filesystem overlay with fully-functional access controls (for
      files and directories) based on path names, access controls for
      sending signals, and file-backed-memory revocation for
      processes.</p>
    </body>
  </project>

  <project>
    <title>SMPng</title>

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

          <common>Baldwin</common>
        </name>

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

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

          <common>Wemm</common>
        </name>

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

    <links>
      <url href="http://www.FreeBSD.org/~jasone/smp/" />
    </links>

    <body>
      <p>Updates to things from last month: 
      <ul>
        <li>The ast() fixes were committed last month.</li>

        <li>The work on the preemptive kernel is stalled for the time
        being. It is still unstable on Alpha and SMP systems.</li>
      </ul>
      </p>

      <p>New stuff since last month: 
      <ul>
        <li>sx locks now support upgrades and downgrades.</li>

        <li>Witness now supports lock upgrades and downgrades.</li>

        <li>Jason Evans has committed a semaphore implementation.</li>

        <li>Matt Dillon has pushed Giant down into all of the
        syscalls.</li>

        <li>John Baldwin has been working on proc locking in a p4
        'jhb_proc' branch.</li>

        <li>John is also currently working on making the ktrace code
        use a work thread to asynchronously write trace data out to the
        trace file. This will make ktrace safe almost completely MP
        safe with the exception that a few ktrace events need Giant in
        order to call malloc(9) and that ktrgenio() is still
        synchronous. Specifically, however, ktrpsig(), ktrsysret(), and
        ktrcsw() no longer need Giant.</li>

        <li>Jonathan Lemon has started work on locking the network
        stack in a p4 'netlock' branch.</li>
      </ul>
      </p>
    </body>
  </project>

  <project>
    <title>FreeBSD Java Project</title>

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

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

        <email>glewis@eyesbeyond.com</email>
      </person>
    </contact>

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

    <body>
      <p>Most of the work this month has focused on development of the
      native JDK 1.3.1 patchset. The 3rd patchset is out and has been
      accompanied with the creation of a FreeBSD "port". This has
      allowed early adopters much easier access to the code and
      naturally resulted in a number of bugs being found. Development
      work has mostly focused on fixing these problems and the project
      is now set to release fourth patchset over the weekend, which
      should see the JDK in a reasonably usable state. One of the big
      challenges left is producing a working HotSpot JVM, which looks
      like it will require some heavy hacking.</p>

      <p>We also welcome OpenBSD's Heikki Korpela to the porting team
      :)</p>
    </body>
  </project>

  <project>
    <title>floppy driver overhaul</title>

    <contact>
      <person>
        <name>
          <given>Joerg</given>

          <common>Wunsch</common>
        </name>

        <email>j@uriah.heep.sax.de</email>
      </person>
    </contact>

    <body>
      <p>As part of some ongoing development activity, the floppy
      driver (fdc(4)) enjoyed some overhaul in the past which is part
      of an ongoing process. Automatic density selection will come
      next, something i meant to implement for years now. As part of
      that, the entire density selection stuff has been rewritten. 2.88
      MB floppies are on the wishlist as well, but I need a working
      2.88 drive before attempting to implement that.</p>
    </body>
  </project>

  <project>
    <title>sppp(4) merge</title>

    <contact>
      <person>
        <name>
          <given>Joerg</given>

          <common>Wunsch</common>
        </name>

        <email>j@uriah.heep.sax.de</email>
      </person>
    </contact>

    <body>
      <p>sppp(4) should be merged with the ISDN4BSD offspring variant.
      This will merge some features and bugfixes from the i4b branch
      (like VJ compression), and eventually end up in a single sppp(4)
      in the tree. While being at that, incorporating many changes and
      bugfixes from NetBSD is considered as well.</p>
    </body>
  </project>

  <project>
    <title>KAME</title>

    <contact>
      <person>
        <name>
          <given>Munechika</given>

          <common>Sumikawa</common>
        </name>

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

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

    <body>
      <p>The KAME project (http://www.kame.net/) has merged its IPv6
      and IPsec implementation as of July 2001 to FreeBSD CURRENT and
      STABLE, in cooperation with some contributors of the project. The
      latest code includes a number of bug fixes, has been fully tested
      in FreeBSD STABLE, and will appear in FreeBSD 4.4 RELEASE. Thus,
      the new RELEASE version will be quite stable in terms of IPv6 and
      IPsec.</p>

      <p>The project has assigned a talented guy to be responsible for
      merge from KAME to FreeBSD, so future merge efforts will be
      smoother.</p>
    </body>
  </project>

  <project>
    <title>TrustedBSD</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/" />
    </links>

    <body>
      <p>The TrustedBSD project continues to move ahead, with progress
      made in the ACL, Capability, and MAC implementations. In
      addition, support from DARPA is permitting new work to improve
      the extended attribute code, improve security abstractions, and
      work on security documentation. Due to the push-back of the
      FreeBSD 5.0 release, it should now be possible to include a
      complete MAC implementation in that release. Specific status
      reports appear for components where substantial progress is being
      made.</p>
    </body>
  </project>

  <project>
    <title>TrustedBSD Capabilities</title>

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

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

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

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

          <common>Moestl</common>
        </name>

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

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

    <body>
      <p>Capabilities support is currently being committed to the base
      FreeBSD tree--userland libraries are now fully committed, and
      kernel infrastructure is being integrated.</p>
    </body>
  </project>

  <project>
    <title>BSDCon Europe</title>

    <contact>
      <person>
        <name>
          <given>Paul</given>

          <common>Richards</common>
        </name>

        <email>paul@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>Planning for BSDCon Europe is going well. We're still
      accepting proposals for talks but the schedule is starting to
      fill up so we may not be for much longer.</p>

      <p>An update of the site that includes accommodation information,
      a preliminary schedule, a list of speakers and an online payment
      page will be launched on Wednesday 19 September.</p>

      <p>The fee will be &#163;150 for individuals and &#163;250 for
      corporations. The individual pricing is valid only until the end
      of September, the price will rise to &#163;200 for October and
      late registrations in November will be &#163;250.</p>

      <p>The updated website will include a list of sponsorship
      options, we're still looking for more sponsorship.</p>
    </body>
  </project>
</report>
