<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE news PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
Ideas//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/ideas.dtd">

<!-- Simple schema for FreeBSD Project feature request ideas.

     Top level element is <ideas>, which contains a collection of
     <category>s.  Each category contains a <title> element, and a
     collection of <idea> elements.

     Each <idea> contains a <title>, <desc>, and <requirements>.
-->

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

  <category>
    <title>Embedded</title>

    <idea id="reduced-size-kernel">
      <title>Reduced FreeBSD kernel size for embedded</title>
      <desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

      <p>The FreeBSD kernel has been optimized over the years for a
	server or workstation environment.  Memory is plentiful in these
	environments, so little attention was given to the size of the
	kernel.  There's a number items in the kernel that can be made
	optional without reducing affecting the functionality needed in
	an embedded environment.  These include things like not
	compiling in strings into the kernel, less aggressively inlining
	code, making some non-optional features optional and investigating
	compile time flags.  This task requires identifying potentially
	optional kernel content and building the infrastructure to make
	that content optional.</p>
      <p><strong>requirements</strong>:</p>
      <ul>
	<li>Strong C language programming skills.</li>
	<li>Understanding of system calls and general kernel architecture.</li>
      </ul>
      </desc>
    </idea>

    <idea id="bus-abstraction">
      <title>Make creating a bus easier</title>
      <desc><p><strong>Technical Contact</strong>: <a
  href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
      <p>There's about a dozen busses in the tree now that manage resources and
activate children.  They are far too hard to create.  We need to
abstract out the basics for these buses and provide a way to allow
these buses to be a subclass of this new base class.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good C programming skills</li>
  <li>Good knowledge of the NewBus configuration system in FreeBSD</li>
</ul>
      </desc>
    </idea>

    <idea id="arm-cleanup">
      <title>ARM cleanup</title>
      <desc><p><strong>Technical Contact</strong>: <a
  href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

      <p>Adding a new board to the arm code is a lot harder than it
        needs to be.  A lot of benefit could be had by creating tables
        for memory ranges, etc, and having more generic initialization
        code.  Much of this can also be Machine Independent (MI).</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good C programming skills</li>
  <li>Good refactoring skills</li>
</ul>
      </desc>
    </idea>

    <idea id="ppc-bringup">
      <title>PPC/ARM/MIPS bring up</title>

      <desc><p><strong>Technical Contact</strong>: <a
  href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

      <p>There's a number of SoCs that are in consumer grade routers,
        etc that have chips that are supported by FreeBSD, or nearly
        supported by FreeBSD.  Pick one and bring FreeBSD up on it.
        Integrate it into the tree.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good C programming skills</li>
  <li>Good kernel debugging skills</li>
</ul>
      </desc>
    </idea>

    <idea id="mips-superpages">
      <title>Add super page support to MIPS</title>

      <desc><p><strong>Technical Contact</strong>: <a
  href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

      <p>Superpage support exists only for x86-based architectures at the
        moment.  MIPS hardware supports a number of different page sizes
        on a per page basis.  This could be used to implement superpages
        for MIPS(which just uses two sizes: 4k chunks and 4M chunks).  The
        vm system supports it generically for all platforms, but the pmap
        for each platform must complete the implementation.  Fortunately,
        superpages were MFC'd as one huge commit into FreeBSD 7.x, so
        finding the relevant changes that need to be made to the mips pmap
        won't be starting from scratch.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong C programming skills</li>
  <li>Strong kernel skills</li>
  <li>Strong VM skills</li>
</ul>
      </desc>
    </idea>

    <idea id="overhaul-config">
      <title>Overhaul the config system</title>

      <desc><p><strong>Technical Contact</strong>: <a
  href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

      <p>Right now the kernel is built twice: once for the static
        modules in the kernel, and once for the dynamically loaded.
        There's also inconsistent dependency tracking.  We should fix
        this.  Bikeshed included, along with three colors of
        paint.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good C programming skills</li>
  <li>Good kernel debugging skills</li>
  <li>Ability to withstand Bikesheds</li>
</ul>
      </desc>
    </idea>

  </category>

  <category>
    <title>File System</title>

    <idea id="extenddump">
      <title>Improve the performance of dump/restore</title>

      <desc><p>A performance evaluation of the split cache (as is) and an unified cache
  (like e.g. NetBSD) would be interesting.  More details in <a
    href="http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html">
  this</a> mail to the hackers mailing list.  Additional improvements are
  welcome too.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Knowledge of C programming.</li>
  <li>Basic understanding of backup/restore procedures.</li>
</ul>
      </desc>
    </idea>

    <idea id="portext2fs" class="soc2009">
      <title>Analyze NetBSD's ext2fs regarding valuable improvements</title>

      <desc><p>FreeBSD has an implementation of the ext2fs filesystems
        but it contains some files under the GPL which make it undesirable,
        among other things, to use it in the GENERIC kernel. Ext2fs is a rather
        simple but practical filesystem and NetBSD has had for <a
        href="http://ezine.daemonnews.org/200006/ext2fs.html">a while</a>
        an <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/ufs/ext2fs/">
        implementation</a> based on UFS1 sources. The NetBSD implementation
        needs to be analyzed regarding features and performance. If it is
        on par or better with our GPLed implementation, it should be
        ported to FreeBSD.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Knowledge of C programming.</li>
  <li>Basic understanding of filesystems.</li>
</ul>
      </desc>
    </idea>

    <idea id="ext34fs" class="soc">
      <title>Enhance FreeBSD ext2fs to support preallocation, ext3, and
	ext4</title>

      <desc><p><strong>Technical contact</strong>: <a
	href="mailto:lulf@FreeBSD.org">Ulf Lilleengen</a></p>

      <p>During Google Summer of Code, Aditya Sarawgi created a GPL-free
	implementation of ext2fs for FreeBSD, which has now been completed.
	However, there are several avenues for potential further work:</p>

      <ul>
	<li>Implement preallocation in ext2fs; the GPL-licensed preallocation
	  code present in the previous implementation was removed, but it may
	  well be desirable to add it back.  This should be driven by
	  benchmarking and performance analysis.</li>
	<li>Update ext2fs to be able to read ext4 file systems, and possibly
	  add other functionality from newer ext file system versions.</li>
      </ul>
      </desc>
    </idea>

    <idea id="portntfs" class="soc">
      <title>Port Darwin's NTFS implementation</title>

      <desc>
	<p>The <a href="http://www.opensource.apple.com/source/ntfs/ntfs-65.2/kext/">Kernel</a>
	  part of NTFS implementation on Mac OS X is dual licensed under both a
	  3-clause BSD and GPL license, and supports writing.</p>
      </desc>
    </idea>

    <idea id="portudf" class="soc">
      <title>Port NetBSD's UDF implementation</title>

      <desc><p><strong>Technical Contact</strong>: <a
	href="mailto:avg@FreeBSD.org">Andriy Gapon</a></p>

      <p><strong>Technical references</strong>:
        M. McKusick, G. Neville-Neil, <a
	href="http://www.awprofessional.com/titles/0201702452">
	The Design and Implementation of the FreeBSD Operating System
	</a>
	(ISBN 0-201-70245-2), <a
        href="http://www.osta.org/specs/pdf/udf260.pdf">UDF 2.60 OSTA
	Specification </a>
	, <a
	href="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf">
	Volume and File Structure for Write-Once and Rewritable Media
	using Non-Sequential Recording for Information Interchange
	</a></p>

      <p>FreeBSD has an implementation of the UDF filesystem
        but it is quite aged and doesn't support many features from newer UDF
	revisions (&gt;=2.01), it's also readonly.
	NetBSD implementation by Reinoud Zandijk supports most of UDF features
	and has write support too. Initial port could be readonly so that
	at least newer pre-authored media (e.g. BD) is accessible.
	Porting write support is a bit trickier.
        </p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C programming.</li>
  <li>Basic understanding of VFS, buffer cache and filesystem implementation.</li>
</ul>
      </desc>
    </idea>

    <idea id="colocation">
      <title>Implement co-location for UFS2</title>

      <desc><p>While FreeBSD's FFS includes many advanced features, such as
	snapshots and soft updates, Greg Granger <a
        href="http://www.ece.cmu.edu/~ganger/papers/cffs.html">has proposed</a>
        other strategies that would be useful, especially when working
        with small files. Quoting Greg Ganger: "The key insight for why
        current file systems perform poorly is that locality is insufficient
        - exploiting disk bandwidth for small data objects requires that
        they be placed adjacently". Explicit grouping, in particular, seems
        to provide important performance improvements without less
        implementation complexity than embedded inodes. As this changes
        the on-disk structure, care needs to be taken that the
        implementation is backwards compatible.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>Knowledge of the UFS2 filesystem.</li>
</ul>
      </desc>
    </idea>

    <idea id="mdfs">
      <title>MDFS lockups</title>

      <desc><p>Fix MDFS lockups when using async operation modes.  <a
  href="&cgibase;/cvsweb.cgi/sys/dev/md/md.c#rev1.115">Revision 1.115 of
  md.c</a> has a discussion of the problem.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>Knowledge of the VFS and VMA subsystems.</li>
</ul>
      </desc>
    </idea>

    <idea id="mpsafe-filesystem-work" class="soc">
      <title>MPSAFE filesystem work</title>

      <desc>
        <p><strong>Technical contact</strong>: <a href="mailto:kib@FreeBSD.org">Konstantin Belousov</a></p>

	<p>FreeBSD 6.0 introduced an multi-processor scalable Virtual File
	  System (VFS) Framework, allowing file systems to operate without the
	  Giant lock.  Many of the most commonly used file systems have been
	  adapted to be MPSAFE (i.e., not reliant on Giant), such as UFS, the
	  NFS client and server, UDF, cd9660, ZFS, and most recently the
	  msdosfs (FAT) file system.  However, in order to remove the
	  compatibility shims permitting a file system to declare itself
	  non-MPSAFE, all file systems must be converted.  The list of
	  remaining file systems includes ntfs, hpfs, coda, smbfs, and ncpfs.
	  This project idea is to take one or more file systems and convert
	  them to use their own locking, rather than relying on the Giant
	  lock.  In some cases, this requires also adapting underlying
	  infrastructure: for example, smbfs relies on the netsmb RPC
	  framework, and ncpfs on the netcp RPC framework, both of which will
	  also require conversion.</p>
      </desc>
    </idea>

  </category>

  <category>
    <title>Kernel</title>

    <idea id="fifo-optimizations" class="soc2009">
      <title>FIFO optimizations</title>

      <desc><p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

      <p>Evaluate the possibility of merging the FIFO implementation
        with the pipe implementation for improved performance.  Care
        would need to be taken to avoid regressions, so part of this
        project should be attention to previous and existing FIFO bug
        reports, and writing of conformance testing to verify correct
        behaviour.  Possible extensions might include a re-evaluation
        of some of the performance tradeoffs made in the pipe code in
        light of modern CPUs.</p>
      </desc>
    </idea>

    <!--
    <idea id="pmc-modern-cpus" class="soc">
      <title>PMC support for modern CPUs</title>

      <desc><p><strong>Technical contact</strong>: <a
	href="mailto:jkoshy@FreeBSD.org">Joseph Koshy</a>,
	href="mailto:gnn@FreeBSD.org">George Neville-Neil</a></p>

      <p>Part of this project would be to add support to PMC for
        running on modern x86 CPUs.  This is a relatively
        self-contained project but requires a bit of immersion in the
        code and the CPU manuals.</p>

      </desc>
    </idea>
    -->

    <idea id="timecounter-perf" class="soc">
      <title>Timecounter Performance Improvements</title>

      <desc>
        <p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

	<p>The gettimeofday syscall is a performance bottleneck in
	  certain applications.  An approach taken by other operating
	  systems is to export the time counter to userland via a
	  shared page, and to update it periodically (a prototype
	  implementation is available).  For some time consumers this
	  is sufficient resolution.  Other consumers need higher
	  resolution.  On the x86 architecture the TSC timecounter can
	  be read from userland.  However depending on the hardware
	  there may be issues with synchronization between CPUs, as
	  well as interaction with CPU frequency changes.  With care
	  it can be used as a delta against the timestamp updated by
	  the kernel to provide improved resolution and avoid the need
	  for the syscall.</p>
      </desc>
    </idea>

    <idea id="autoreport" class="soc">
      <title>Automated kernel crash reporting system</title>

      <desc>
<p><strong>Technical contact</strong>: <a href="mailto:delphij@FreeBSD.org">Xin LI</a>, <a
  href="mailto:howardsu@FreeBSD.org">Howard SU</a></p>

<p>In some recent operating systems, it is common that crashes are
  automatically reported to its vendor, which is very helpful for
  finding hidden problems that can not be easily triggered by usual
  test cases.  Newer GNOME applications also have similar functionalities.</p>

<p>This project would consist two parts.  One is some improvements over
  the current savecore rc.d script to teach it how to collect necessary
  information (of course, automatic reporting has to be explicitly enabled
  by individual system administrators, and should have at least three
  options: not to send out anything at all as a default, send out after
  administrator confirmation, and automatically send all necessary information).
  The FreeBSD kernel in 8-current has the textdump feature which may
  be interesting to use for this part</p>

<p>Another part after the first one is finished is the server side one,
  which will keep a database of backtraces where similar (call stack
  minus addresses) reports are kept together and be considered as a
  "vote", to make it possible for developers and release engineers
  to focus on the most commonly triggered issues.</p>

<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong knowledge of C.</li>
  <li>Understanding of kernel debugging.</li>
  <li>Knowledge about web application as well as database.</li>
  <li>Understanding of user privacy protection.</li>
</ul>
      </desc>
    </idea>

    <idea id="setproctitle" class="soc2007">
      <title>Avoiding syscall overhead</title>

      <desc>
<p><strong>Technical contact</strong>:
  <a href="mailto:attilio@freebsd.org">Attilio Rao</a>,
  <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

<p>setproctitle() calls are a serious
  performance bottleneck in a default pgsql configuration (they are
  called at least once per query, which might be thousands of times per
  second - I measured a performance impact of about 33% on sysbench).</p>

<p>One idea for avoiding the syscall (and global sysctl lock) overhead
  for this kind of thing would be a memory page shared between kernel
  and userland which libc could read/write to access things like the
  process title.  There are potentially many other data values that
  could be optimized by a similar method.  This is presumably a well
  established technique in other OSes.</p>

<p>This project requires mentoring/review/planning with someone with
  significant VM experience to make sure this approach
  works properly.  Done incorrectly, this could result in fairly
  massive security holes, performance issues (perhaps not visible in
  simple benchmarks), etc.</p>

<p>Work is currently in progress on this and is undergoing review.
  It is not complete, but interested parties should contact Attilio
  before beginning work.</p>

<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong knowledge of C.</li>
  <li>Understanding of kernel VM.</li>
</ul>
      </desc>
    </idea>

    <idea id="dynamiccpu" class="soc">
      <title>CPU online/offline project</title>
      <desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:jhb@FreeBSD.org">John Baldwin</a>, <a
	  href="mailto:attilio@FreeBSD.org">Attilio Rao</a></p>

	<p>The project would need to extend the current CPU states of
	  absent and present to include absent, offline, and online.  A
	  set of event handlers (probably using EVENTHANDLER(9)) will
	  need to be created to allow subsystems to be notified of CPU
	  state changes.  At a minimum, the functionality of the
	  current 'hlt_cpus_mask' should be reimplemented in both the
	  4BSD and ULE schedulers using this mechanism.  Note that the
	  ability to disable all but one thread within a core must
	  still be supported easily.  (This is currently done on x86
	  via the machdep.hyperthreading_allowed sysctl.)  Each
	  subsystem that uses CPU_ABSENT() will need to be evaluated to
	  see if it needs updating to handle online vs offline CPUs.
	  Further improvements may include teaching UMA to free per-CPU
	  buckets when a CPU is taken offline.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong knowledge of C.</li>
	  <li>Experience with multi-threaded programming.</li>
	  <li>Experience with kernel programming.</li>
	</ul>
      </desc>
    </idea>

    <idea id="scalableprimitives" class="soc">
      <title>SMP scalability improvements for core primitives</title>
      <desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:attilio@FreeBSD.org">Attilio Rao</a>, <a
	  href="mailto:jhb@FreeBSD.org">John Baldwin</a>.</p>

	<p>FreeBSD SMP scalability has improved dramatically over the last
	  ten years as a result of the now-complete SMPng project, which
	  converted FreeBSD from a single Giant kernel lock to fine-grained
	  locking and strong 8-core scalability.  As commodity hardware is
	  now reaching 16-24 cores, some low-level primitives in the SMP
	  implementation must be revisited.  In particular, 32 or 64-CPU
	  limits are encoded in the CPU mask primitive (cpumask_t), and
	  spin locks offer higher than desired cache line contention as well
	  as unfairness.  This project would combine these two related tasks
	  by improving the expressibility of CPU masks and per-CPU objects
	  and improving the scalability of the spinlock implementation.  It
	  is especially important that the latter portion of the work be
	  driven by real-world measurement using workloads that trigger the
	  specific problem, and experimentation with primitives across
	  several types of hardware.</p>

	<p>Note: a spinlock backoff patch has already been proposed, but not
	  yet properly evaluated, and would make a good starting point for
	  this work.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong knowledge of C.</li>
	  <li>Experience with multi-threaded programming.</li>
	  <li>Experience with kernel programming.</li>
	</ul>
      </desc>
    </idea>

    <idea id="umtx">
      <title>Rewrite umtx - userspace mutex system calls</title>
      <desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:attilio@FreeBSD.org">Attilio Rao</a></p>

	<p>umtx is the underbelly of the FreeBSD pthreads synchronization
	  primitives, allowing kernel-assisted sleeping, wakeups, priority
	  propagation, and other features supporting efficient mutexes and
	  reader-writer locks in userspace.  As kernel features have evolved
	  (such as the addition of a sleepqueue primitive), hardware
	  scalability has grown, and application-writer expectations have
	  changed, some weaknesses have come to light.  In particular, there
	  are concerns about overhead and scalability with highly-threaded
	  applications.  This project would profile and evaluate the existing
	  system call service provided by umtex, and consider cleanups,
	  optimizations, and the application of newer algorithms to improve
	  functionality and performance.  The effectiveness of the rewrite
	  would be demonstrated through careful testing with sensitive
	  workloads, such as MySQL on 16-core systems.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong knowledge of C.</li>
	  <li>Experience with multi-threaded programming.</li>
	  <li>Experience with kernel programming.</li>
	</ul>
      </desc>
    </idea>

      <idea id="docsysctl">
        <title>Document all sysctls</title>
        <desc>
<p><strong>Technical contacts</strong>: <a
  href="mailto:mat@FreeBSD.org">Mathieu Arnold</a>, <a
  href="mailto:brd@FreeBSD.org">Brad Davis</a></p>
<p>The sysctl(8) utility retrieves kernel states and allows processes with
  appropriate privilege to change kernel states.  On request it is able to
  display description lines which document the kernel state.  Unfortunately
  not every sysctl is documented.  This task is possible to share with other
  volunteers.  mat has done some development in Perforce, in the
  mat_sysctl_cleanup branch.</p>
<ul>
  <li>Find every undocumented sysctl in the kernel.</li>
  <li>Try to determine what this sysctl is for and document it.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
</ul>
        </desc>
      </idea>

      <idea id="docsound">
	<title>Document the sound subsystem</title>

	<desc>
<p><strong>Technical contacts</strong>: <a
  href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a>, <a
  href="mailto:ariff@FreeBSD.org">Ariff Abdullah</a></p>
<ul>
  <li>Add sound subsystem related section 9 manual pages, so far no sound
    subsystem related manual pages exists.</li>
  <li>Add an example driver in share/examples which allows to write a new
    driver. For this purpose the example driver should contain enough
    documentation as comments and/or pointers to documentation in man-section
    9. This work can be based upon <a
    href="http://people.FreeBSD.org/~cg/template.c">this template.</a></li>
  <li>Rewrite the sound subsystem chapter in the FreeBSD Architecture Handbook.
    The rewrite should contain an overview of the available parts in the sound
    subsystem and how they interact (data flow, dependencies, ...) and fit
    together. Additionally it should contain links to already available
    documentation (official standards, section 9 manual pages, ...).</li>
  <li>A <a href="http://wiki.freebsd.org/soundsystem">wiki page</a>
    documenting everything related to the sound subsystem in FreeBSD has been
    created.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Documentation writing skills.</li>
</ul>

        </desc>
      </idea>

      <idea id="dtrace" class="soc">
	<title>DTrace</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:sson@FreeBSD.org">Stacey Son</a>, <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p><strong>URL</strong>: <a
  href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/dtrace">Perforce
  repository</a>, <a
  href="http://people.freebsd.org/~jb/dtrace/index.html">DTrace for
  FreeBSD</a></p>
<p>DTrace is a dynamic tracing facility designed by Sun Microsystems and
  released in Solaris 10.  They have since released the major part of
  Solaris under the banner of OpenSolaris and the Common Development and
  Distribution License (CDDL) 1.0.  John Birrell has created an initial port
  provides strong kernel functionality, but significant work remains to be
  done.  Some ideas for projects:</p>
<ul>
  <li>It would be preferable to have a BSD-licensed CTF implementation, but
    this requires careful documentation of the specification and a clean-room
    implementation.</li>
  <li>Tracing of user processes is not supported, and is a highly desirable
    feature.</li>
  <li>It would be quite useful to track changes to DTrace in OpenSolaris since
    the initial port, merging enhancements and bug fixes that apply to
    FreeBSD.</li>
  <li>There has been some work to add static trace points for kernel
    subsystems, such as VFS, the MAC Framework, privilege checking, etc.
    However, it would be useful to add further static trace points to the
    network stack, disk I/O subsystems, GEOM, etc.  It would be useful to do
    this in a similar way to Solaris so that Solaris monitoring scripts could
    be used in FreeBSD.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>A good understanding of the FreeBSD kernel.</li>
</ul>
	</desc>
      </idea>

      <idea id="assembler">
	<title>DWARF2 call frame information</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:kib@FreeBSD.org">Konstantin Belousov</a></p>
<p>A debug kernel is not able to show stack traces with cross exceptions
  anymore.  This is because we do not emit any dwarf2 call frame information
  for any assembler code, since gdb switched to the dwarf2 format.  A volunteer
  should annotate every assembler file [*.[sS]] with dwarf2 call frame
  information.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Knowledge of assembly code.</li>
  <li>Knowledge of ".cfi_*" pseudo-ops to insert dwarf2 frame descriptors.</li>
</ul>
	</desc>
      </idea>

    <idea id="kernel-dvb" class="soc">
      <title>Kernel support for linux DVB device drivers</title>

      <desc>
<p><strong>Technical contact</strong>: <a href="mailto:luigi@FreeBSD.org">Luigi Rizzo</a></p>

<p>In early 2007 we started a project to support
  building Linux device drivers on FreeBSD.
  This was done through an in-kernel emulation layer, which
  implements part of the linux kernel API on top of the FreeBSD
  kernel API.  The initial implementation was good enough to
  support a few USB webcam drivers, and is documented 
  <a
href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.
  The code is actually available as a port, devel/linux-kmod-compat,
  and a popular driver that uses this infrastructure is
  multimedia/linux-gspca-kmod.
</p>
<p>We would like to use a similar approach to add support
  for DVB devices, which are widely supported in Linux
  but not in FreeBSD. In particular we expect the project to provide,
  within the FreeBSD kernel, enough of linux compatibility to build
  the core components of the drivers/media/ linux kernel, and then
  a few device drivers including one for a PCI DVB card (e.g.
  saa7134-based).
</p>

<p>Before the start of the project, a Summer of Code applicant is expected to
  i) become familiar with the approach used by linux-kmod-compat;
  ii) set up a proper test environment, with a couple of DVB devices
  supported by linux, and a working linux installation so that
  one can compare results;
  iii) become familiar with the architecture of the linux code in
  drivers/media.
<br/>
  Probably the attention should be focused in PCI devices, because
  at this stage the USB stack is in a transition phase and would
  pose some additional difficulties.
</p>
<p>
  Expected results are a working porting infrastructure, a working
  linux-dvb-kmod device driver, and a working application to demonstrate
  that the driver is working as expected. We suggest to look at
  "kaffeine" for which a FreeBSD port already exists.
</p>
      </desc>
    </idea>

      <idea id="ktrace">
	<title>Extend ktrace/kdump output</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a></p>
<p>The ktrace(1) facility allows to monitor what running processes do.  It
  allows to determine if a process is stuck or if it still does useful work.
  The goal of this item is to look at the kernel interfaces, add missing
  "pieces" (e.g. syscall's) to the ktrace output and to extend the output
  with "decoded" (translating hex/dec values into human readable
  information, e.g. O_RDONLY in the case of open(2)) information.  Some work
  has been completed and committed, but a few parts still remains.  More
  information is available <a
  href="http://lists.freebsd.org/pipermail/freebsd-arch/2006-April/005107.html">here</a>.</p>
<p>Also, a related project would be to modify ktrace to write to pipes.
  Currently the ktrace infrastructure requires the dump output go to a file.
  It would be useful to be able to instead have it write to pipe, or in fact
  any type of file descriptor.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Knowledge of C.</li>
  <li>Good knowledge of POSIX interfaces or how to use man(1).</li>
  <li>No fear to look into the kernel sources.</li>
</ul>
	</desc>
      </idea>

      <idea id="fastcall" class="notsoc">
	<title>Fast syscall support for FreeBSD/i386</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:attilio@FreeBSD.org">Attilio Rao</a>, <a
  href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>
<p>The instruction pair sysenter and sysexit can contribute to certain
  performance improvements when a syscall is made on IA32.  There is however
  no implementation of this available for FreeBSD, so a volunteer
  would have to add sysenter/sysexit support to the kernel.  This
  needs to be properly evaluated and benchmarked though, so a complete
  implementation should therefore also contain informative benchmarks which
  shows a clear improvement in performance.  It is also important to stress
  the fact that this project is of research quality and measures should be
  taken to ensure that no regressions are introduced.  Another interesting
  extension to this project would be to investigate and evaluate the
  possibility to use mmx/xmm registers to gather syscalls arguments.
  <a href="mailto:davidxu@FreeBSD.org">David Xu</a> has some <a
  href="http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064403.html">work
  in progress</a> in his <a
  href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/davidxu/sysenter">sysenter</a>
  branch in the perforce repository.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>Ability to write and understand x86 assembly.</li>
</ul>
	</desc>
      </idea>

      <idea id="geninput" class="soc2007">
	<title>Generic input device layer</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:philip@FreeBSD.org">Philip Paeps</a></p>
<p><strong>WIP</strong>: <a href="http://wiki.freebsd.org/GenericInputDeviceLayer">http://wiki.freebsd.org/GenericInputDeviceLayer</a></p>
<p>The kernel is lacking a generic input device layer analogous to the Linux
  'input core' layer.  Having such a layer would make it easy to write e.g.
  touchscreen support (Philip Paeps has some work-in-progress regarding pointer
  devices and touchscreen support, but not enough time to also cover keyboard
  support or other generic features).  This project was worked on as part of
  Google Summer of Code 2007, and you can find <a
  href="http://wiki.freebsd.org/GenericInputDeviceLayer">more information on
  the FreeBSD.org wiki</a></p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
</ul>
	</desc>
      </idea>

    <idea id="interactive-splash">
      <title>Interactive Splash Screen</title>

      <desc><p>Improve upon / replace the existing static VESA splash
        screen support in FreeBSD, with a script-driven back-end,
        which allows animation in the loading graphics. This would
        greatly improve the bootup experience for desktop users, while
        providing graphical feedback to the startup of the kernel /
        system services. Additionally this could be used to replace
        the beastie.4th menu, with a VESA driven graphical loader
        screen.</p></desc>
    </idea>

      <idea id="pcihotplug">
	<title>PCI-Hotplug support</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:bms@FreeBSD.org">Bruce M. Simpson</a></p>
<p><!-- Description needed --></p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>A good understanding of low-level access of the hardware.</li>
  <li>A good understanding of FreeBSD device drivers.</li>
</ul>
	</desc>
      </idea>

      <idea id="per-job-limits" class="soc">
	<title>Collective limits on set of processes (a.k.a. jobs)</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:brooks@freebsd.org">Brooks Davis</a></p>

<p>In SGI's Irix operating system, there is a concept of a job which is
  a collection of processes.  These processes share a set of resource
  limits similar to those accessible through the set/getrlimit and
  getrusage system calls.  Schedulers such as Sun Grid Engine currently
  implement tracking the processes that make up a job and enforcing
  collective limits on them in an adhoc manner.  Having first class
  kernel support would be useful.</p>

<p>It seems most likely that implementing something like the Irix
  interface would be the most useful approach since that would enable us
  to leverage existing code.  Implementers will need to make sure that
  the job construct has no negative performance implications when not
  enabled (ideally, processes that are not part of jobs should be
  unaffected) and quantify the impact on performance when enabled.</p>

<p><strong>References</strong>: <a
  href="http://techpubs.sgi.com/library/tpl/cgi-bin/browse.cgi?cmd=search&amp;coll=0650&amp;db=man&amp;pth=&amp;srch=jid_t&amp;searchpth=man&amp;rpt=20">Irix
  Man Pages mentioning jid_t</a></p>

<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
  <li>Kernel awareness.</li>
  <li>Ability to implement functionality from interface specifications.</li>
</ul>
	</desc>
      </idea>

      <idea id="psched" class="soc2009">
	<title>Geom-based Disk Schedulers</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:luigi@freebsd.org">Luigi Rizzo</a></p>
<p>In a 2005 GSoC project, "Pluggable Disk Schedulers", Emiliano
  Mennucci explored the feasibility of pluggable disk schedulers
  for FreeBSD. The project was successful, but we could not explore
  certain approaches (e.g. "anticipation", where requests are delayed
  hoping that some future ones can served without a seek) due to
  architectural limitations the kernel had at the time.
</p>
<p>
  Since then, the GEOM infrastructure has become available on FreeBSD
  for interacting with disk I/O requests. GEOM has enabled us to
  work on disk schedulers in a much more flexible way, allowing a
  much faster development of disk scheduling algorithms. With
  Fabio Checconi, we have developed a prototype
  implementation of some anticipatory schedulers, see
  <a href="http://info.iet.unipi.it/~luigi/FreeBSD/#geom_sched">GEOM_SCHED</a>.
</p>
<p>
  GEOM_SCHED works within the geom layer, i.e. above the device driver
  where queueing of requests may actually occur. The way GEOM_SCHED
  does scheduling is by limiting the number of outstanding requests
  to the device, and the performance implications of this approach
  need to be measured. An alternative approach is to push the
  scheduler (using the same algorithms developed in GEOM_SCHED,
  and most likely the same code) within the device drivers. This less general
  (as it needs to be replicated in all drivers) but it may be
  an interesting thing to do e.g. for some popular device drivers
  such as ATA.
</p>
<p>
  The proposed SoC work can address one or more of the following
  aspects:
<ul>
<li>implement suitable classifiers for disk requests;</li>
<li>implement techniques for the auto-tuning of
  the scheduler parameters;</li>
<li>measure the performance implications
  of doing scheduling above the device driver, and possibly design
  and implement a suitable mechanism to push the GEOM_SCHED
  module within the device driver itself.</li>
</ul>
  Ultimately, we expect to end up with a production quality subsystem
  for use in FreeBSD.
</p>
<p><strong>References</strong>: <a
  href="http://wiki.freebsd.org/moin.cgi/Hybrid">The Pluggable Disk
  Schedulers SoC project</a>, <a
  href="http://www.happyemi.org/hybrid/">Patches</a></p>

<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>Knowledge of GEOM (or interest in getting familiar with it).</li>
</ul>
	</desc>
      </idea>

      <idea id="suspend">
	<title>Suspend to disk</title>

	<desc>
<p>Implement a suspend/resume from disk mechanism.  Possibly use the dump
  functions to dump pages to disk, then use ACPI to put the system in S4 or
  power-off.  Resume would require changes to the loader to load the memory
  image directly and then begin executing again.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
  <li>Understanding of the hardware/software interface.</li>
  <li>A laptop that works with ACPI.</li>
  <li>Kernel awareness.</li>
</ul>
	</desc>
      </idea>

      <idea id="bootcode">
	<title>Sync FreeBSD i386 boot code with DragonFly</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:jhb@FreeBSD.org">John Baldwin</a></p>
<p>DragonFly invested a lot of time to clean up and document it.  Additionally
  they fixed some bugs.  Interesting files in the DragonFly CVS are
  sys/boot/i386/bootasm.h, sys/boot/i386/bootasmdef.c, sys/boot/boot0/*,
  sys/boot/boot2/*, sys/boot/i386/btx/*, sys/boot/i386/cdboot/*,
  sys/boot/i386/libi386/amd64_tramp.S, sys/boot/i386/libi386/biosdisk.c and
  sys/boot/i386/loader/main.c.  An interested volunteer has to compare and
  evaluate both implementations and port interesting/good parts.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Ability to read and understand foreign C code.</li>
  <li>Ability to write C code.</li>
  <li>Knowledge of i386 assembly.</li>
  <li>Knowledge of BIOS interfaces.</li>
  <li>Knowledge of low-level boot behavior.</li>
</ul>
	</desc>
      </idea>

      <idea id="optreg">
	<title>Make optional kernel subsystems register themselves via sysctl</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
<p>Currently there is no way for e.g., a port makefile to tell whether
  things like FreeBSD 5.x compatibility are present on the system (just
  installing the compat5x port is not enough, you need a kernel built
  with COMPAT_FREEBSD5).  All such optional kernel features need to
  register themselves with the <a
  href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/sysctl.h.diff?r1=1.154;r2=1.155;f=h">FEATURE
  macro</a> so that the userland can easily query whether a given
  feature is present. So far not all kernel features are using this
  infrastructure.</p>
<p>There needs also to be a way to spoof those values, e.g., when the
  ports build cluster is building for older FreeBSD versions in a jail.
  Suport for this is not available in the FEATURE macro.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
  <li>Kernel awareness.</li>
</ul>
	</desc>
      </idea>

      <idea id="efi">
	<title>EFI support for FreeBSD/i386 and FreeBSD/amd64</title>
	<desc>
	  <p><strong>Technical contact</strong>: <a
	    href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>
	  <p>Finish EFI support on the i386/amd64 ports. Final work
	    should be able to boot a FreeBSD kernel into single user
	    mode, at least.</p>

	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>Good knowledge of C.</li>
	    <li>Deep understanding of the boot process and EFI.</li>
	    <li>A system running EFI 1.0 (Intel Macs, for example)</li>
	  </ul>

	</desc>

      </idea>

  </category>

  <category>
    <title>Networking</title>

      <idea id="csup">
	<title>csup improvements</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:lulf@FreeBSD.org">Ulf Lilleengen</a></p>
<p><strong>URL's</strong>: <a
  href="http://mu.org/~mux/csup.html">csup homepage</a>, <a
  href="http://www.freebsd.org/cgi/cvsweb.cgi/projects/csup/">CVSweb</a>
  </p>
<p>csup is a port of the cvsup high-speed CVS repository replication
  application from the original Modula-3 to the C language.  It is now
  distributed with FreeBSD, but is missing some important features that would
  make useful projects to work on:</p>
<ul>
  <li>Working rsync support.</li>
  <li>Optimize rcsfile handling.</li>
  <li>Create a library out of the ports that might be of use in a C language
    csupd.</li>
  <li>Add support for shell commands sent by the server.</li>
  <li>Add missing support for various CVSup options: -D, -e and -E (requires
    shell commands support) and the destDir parameter.</li>
  <li>Work on a new csupd.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong knowledge of C.</li>
  <li>Good knowledge of POSIX standards.</li>
  <li>Ability to work with multi-threaded applications.</li>
</ul>

	</desc>
      </idea>

      <idea class="soc" id="tcpipreg">
	<title>TCP/IP regression test suite</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
  href="mailto:gnn@FreeBSD.org">George V. Neville-Neil</a></p>

<p>Design and implement a wire level regression test suite to exercise
  various states in the TCP/IP protocol suite.  Ideally with both IPv4
  and IPv6 support.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong TCP/IP knowledge.</li>
</ul>
	</desc>
      </idea>

      <idea class="soc2008" id="passivelibpcapdetector">
	<title>Passive libpcap based TCP session anomaly detector</title>

	<desc>
<p><strong>Technical contact</strong>: <a href="mailto:andre@FreeBSD.org">Andre Opperman</a>.</p>

<p>Listens on an interface and tracks all TCP sessions it sees.  In the
  normal case only general information is carried forward (seq#/ack#,
  negotiated SYN/ACK features, etc).  Whenever an anomaly happens -
  that is a duplicate ACK, SACK response, out-of-order segment,
  retransmission or others; it captures those packets into a tcpdump
  file for later deep inspection with Wireshark or other tools.  This
  tool is to be deployed on live hosts and passive monitors to collect
  reliable condensed data about real-world behavior of TCP on the
  global Internet.  Currently no such quantitative data exist and
  contribution of such a tool that can be easily run is a significant
  step in helping further development of TCP algorithms.</p>

<p><strong>Difficulty</strong>: Medium, good familiarity with the TCP RFCs is
  necessary and detection of many edge cases has to be implemented correctly.</p>
       </desc>
      </idea>

      <idea id="wpa2preauth" class="soc">
	<title>WPA2 preauthentication in hostapd</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:sam@FreeBSD.org">Sam Leffler</a>, <a
  href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>
<p>WPA2 is the authentication protocol defined as part of the IEEE 802.11i
  specification.  This protocol is now commonly used to authenticate
  wireless stations to access points.  Part of this protocol is the
  ability to pre-authenticate a station with one or more access points
  so that roaming can happen quickly.  FreeBSD lacks support for this
  aspect of the protocol in the hostapd program used to construct a
  WPA-enabled access point.  This task would port the Linux code that
  exists to support pre-authentication in hostapd.  This mostly involves
  rewriting some user-mode multicast code and testing the result.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
  <li>Wireless networking fundamentals.</li>
  <li>WPA-capable wireless network setup.</li>
</ul>
	</desc>
      </idea>

      <idea id="80211testing" class="soc">
	<title>802.11 Fuzzing and Testing</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:sam@FreeBSD.org">Sam Leffler</a>,<a
  href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>
<p>Build a "packet fuzzer" tool that can be used to build test suites to
  improve reliability of the 802.11 code against garbage data.  There are
  various tools out but we're not aware of any good ones that work with 802.11
  and are generally available.  The basic idea is to write a packet
  injector/playback tool that's driven by a scripting language.  Then you
  need to build up a database of test cases.  It's also possibly important
  to do time-based playback.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
  <li>Wireless networking fundamentals.</li>
  <li>WPA-capable wireless network setup.</li>
</ul>
	</desc>
      </idea>

      <idea id="sctp">
        <title>SCPS, Space Communication Protocol Standards</title>

        <desc><p><a href="http://www.scps.org">SCPS</a> is a protocol suite
          designed to allow communication over challenging
          environments.  Originally developed jointly by NASA and
          DoD's USSPACECOM, these protocols are used for commercial,
          educational, and military environments.  A student project
          in this area would involve implementing various network
          protocols according to specification (SCPS File Protocol,
          similar to FTP; SCPS-Transport Protocol, based on TCP; and
	  others.)</p>
        </desc>
      </idea>

      <idea id="tcp-uto" class="soc2009">
	<title>Implement TCP UTO</title>
	<desc>
	  <p><strong>Technical contact</strong>: <a
	    href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>

	<p>Implement TCP UTO (User Timeout Option) as defined by RFC
	5482.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Good knowledge of C and TCP.</li>
	  <li>Able to understand the FreeBSD TCP/IP stack.</li>
	  <li>A testbed with at least two machines.</li>
	</ul>

	</desc>
      </idea>


    <idea id="multiqbpf" class="soc">
      <title>Multiqueue BPF support and other BPF features</title>

      <desc><p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>

	<p>The Berkeley Packet Filter (BPF) allows packet capture filters to
	  be compiled into a bytecode that is either interpreted by a kernel
	  virtual machine, or compiled into native machine code via a JIT and
	  executed in in-kernel.  Historically, the origin of packets has
	  been the network interface, with each (synthetic) BPF device
	  attached to exactly one NIC as requested by the application (for
	  example, tcpdump).  However, network interfaces have become
	  significantly more complicated, and BPF has had to grow to support
	  new features, such as Data Link Types (DLTs), in which BPF devices
	  can tap network processing at different layers.  This task would
	  involve teaching BPF about a further dimension in network interface
	  complexity: multiple input and output queues.</p>

	<p>Modern 10gbps, and even 1gbps, network cards support multiple
	  queues for various reasons: at first quality of service (QoS)
	  differentiation in processing, but now especially to improve
	  parallelism in network processing by distributing work to many CPUs
	  on input.  This same technica can also accelerate packet capture,
	  but BPF currently doesn't know this.  In this project, BPF would be
	  enhanced to be aware of individual input and output queues on a NIC,
	  which means providing network stack abstractions for these concepts,
	  visible today only within device drivers.  Userspace threads might
	  then use enhanced ioctl(2)s to query the set of available queues
	  and attach to one or more.  Applications seeking maximum parallelism
	  could open (n) devices, attaching each to a queue, and executing
	  with appropriate CPU affinity.  Ideally this would involve neither
	  lock nor cache line contention throughout the entire stack, from
	  device driver to userspace delivery.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong knowledge of C.</li>
	  <li>Experience with multi-threaded programming.</li>
	  <li>Experience with kernel programming.</li>
	  <li>Familiarity with the TCP/IP protocol suite.</li>
	</ul>
      </desc>
    </idea>

    <idea id="80211sim" class="soc">
      <title>Implement a simulated 802.11 wireless radio</title>
      <desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>

	<p>The FreeBSD 802.11 layer, net80211, implements a broad range of
	  advanced functionality: station, access point, virtual access
	  point, mesh networking, authentication/encryption, and more.  This
	  task implements a net80211 driver simulating a wireless radio in
	  order to allow protocol-layer testing without the hassle of real
	  live hardware limitations: interference, signal propagation, and
	  regulatory domains.  The driver should let the user specify a
	  number of radios to be simulated, with an eye towards future work
	  to simulate physical properties.</p>

	<p>A useful reference for this work would be the notionally similar
	  mac80211_hwsim driver in Linux
	  (http://linuxwireless.org/en/users/Drivers/mac80211_hwsim), which
	  might provide a model in some areas of the work, and has similarly
	  been used on that platform to test hostapd/wpa_supplication.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Good knowledge of C.</li>
	  <li>Wireless networking fundamentals.</li>
	</ul>
      </desc>
    </idea>

  </category>

  <category>
    <title>Ports</title>
      <idea id="ports-pkgtools">
	<title>Package tools improvements</title>

	<desc>
<p>The pkg_* tools, which deal with the installation of pre-build binary package
  of ports, could do with a code cleanup or maybe even a rewrite from
  scratch.  Some features of the ports tree are not supported by the pkg_* tools,
  e.g. versioned dependencies.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong knowledge of C code.</li>
  <li>A basic understanding of the inner workings of the ports tree.</li>
</ul>
	</desc>
      </idea>

      <idea id="fat-pkgs" class="soc">
	<title>Complete (a.k.a. Fat) packages</title>
	<desc>
	  <p><strong>Technical contact</strong>: <a
	    href="mailto:brooks@FreeBSD.org">Brooks Davis</a></p>
	  <p>When bootstrapping systems it would be useful to be able to
	    create a single package file that contains one or more packages
	    and all the required dependent packages.  This is conceptually
	    similar to, but different from PC-BSD's PBI package format.
	    PBI's contain a private copy of all dependencies, fat packages
	    would contain each individual package and once installed it would
	    be as though each package was individually installed in the usual
	    manner.</p>
	  <p>This project would consist of additions to the pkg_tools
	    to support creation and installation of a new package file format
	    and to ports to build these packages.</p>
	  <p><strong>Requirements</strong>:</p>
          <ul>
	    <li>Strong knowledge of C code.</li>
	    <li>A basic understanding of the inner workings of the ports tree.</li>
	  </ul>
	</desc>
      </idea>

      <idea id="ports-performance" class="soc">
      	<title>Performance improvement of the Ports system</title>

	<desc>
	  <p>A number of tasks of the Ports system can take quite a long time
	    to perform.  Some are well known for traversing each and every port
	    in the tree, e.g. building INDEX, which does not scale well with
	    the number of ports being added to the collection.</p>
	  <p>Detailed profiling of the most used commands in the ports
	    framework needs to be done to analyze the bottlenecks and identify
	    possible solutions.  Refactoring of the main file bsd.ports.mk
	    is also necessary to improve code readability, but not at the
	    cost of performance.</p>
	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>Strong knowledge of make and shell code.</li>
	    <li>Good understanding of the inner design of the Ports Collection.</li>
	  </ul>
	</desc>
      </idea>

  </category>

  <category>
    <title>Security</title>
      <idea id="auditkernel" class="soc">
	<title>Audit kernel event sources</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>
A number of kernel security subsystems, such as IPFW and pf, generate
security log data.  This task involves identifying potential sources of
security event information in the kernel and modifying kernel subsystems to
log that information using the kernel security event auditing system.
User and programmer documentation of audit may be found on the <a
href="http://www.trustedbsd.org/docs.html">TrustedBSD Documentation Page</a>.
There are also extensive manual pages relating to audit in FreeBSD.  This
project will require careful security analysis and kernel programming, and
will likely need some re-working of the kernel audit framework (which is
currently entirely focused on gathering user and kernel system call audit
data).
</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong C programming skills.</li>
  <li>Familiarity with concurrent programming techniques.</li>
  <li>General understanding of TCP/IP firewalls.</li>
  <li>Willingness to read the CC/CAPP specification.</li>
</ul>
	</desc>
      </idea>

      <idea id="distribaudit" class="soc">
	<title>Distributed audit / log shipping daemon</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
  href="mailto:simon@FreeBSD.org">Simon Nielsen</a><br />
<strong>WIP</strong>: <a
href="http://wiki.freebsd.org/DistributedAuditDaemon">http://wiki.freebsd.org/DistributedAuditDaemon</a></p>
<p>Create a tool to securely and reliably ship log files to remote hosts.
The main focus is to manage per-machine audit records and submit them
to a central site for processing and long-term archiving/management.
Ideally with support for SSL (or the like) so they do not travel on
the wire in the clear.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong (portable) C programming skills.</li>
  <li>Knowledge of the audit subsystem.</li>
  <li>OpenSSL knowledge a plus.</li>
</ul>
	</desc>
      </idea>

      <idea id="mac" class="soc">
	<title>Mandatory Access Control</title>
	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>
FreeBSD 5.0 was the first FreeBSD release to ship with support for Mandatory
Access Control (MAC), an access control technology allowing system
administrators to implement multi-level security, integrity protection, and
other "mandatory" policies.  Policies may be compiled into the kernel, or
loaded as loadable kernel modules.
Later revisions of FreeBSD and the MAC Framework enhanced MAC support,
and additional policy modules were made available, such as a port of the
SELinux FLASK/TE framework available as a third party policy module.
However, many of the sample MAC modules included with FreeBSD are considered
experimental examples of what the technology can be used for, rather than
production policies.
For example, the Biba integrity policy can be deployed in production, but
requires significant tuning to do so effectively.
</p>
<p>
This task involves a general review of the MAC Framework and Policy modules,
with the goal of identifying improvement areas.  It also involves specific
cleanups, optimizations, and completeness work on specific policy modules --
most importantly, the Biba and MLS sample labeled policy modules.  Work there
includes improving memory overhead and efficiency; for example, moving from
allocating complete labels for every labeled object to referencing common
label storage where labels are identical, which occurs a great deal of the
time in most systems.
Other cleanups include moving towards a canonical/extensible on-disk label
storage format, adding regression tests, investigating interactions with user
applications, and writing documentation.
</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong C programming skills.</li>
  <li>Familiarity with OS security policies, including discretionary and
    mandatory access control.</li>
  <li>Familiarity with concurrent programming techniques.</li>
  <li>Willingness to read the CC/CAPP specification.</li>
</ul>
	</desc>
      </idea>

      <idea id="mac_policy" class="soc">
	<title>Path-based file system MAC policy</title>
	<desc>
	  <p><strong>Technical contact</strong>: <a
	    href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	  href="mailto:trustedbsd-discuss@TrustedBSD.org">TrustedBSD discuss
	  mailing list</a></p>
	  <p>The TrustedBSD MAC Framework makes it easy to extend the FreeBSD
	    kernel security model using pluggable modules, which has provided
	    support for "traditional" mandatory access control, as well as
	    allowed a number of companies to build local security policy
	    extensions for workstation, server, and appliance products; one
	    such example is Apple's "Seatbelt" policy for Mac OS X.  However,
	    the base system MAC policies are difficult to use, primarily
	    because they either don't extend security meta-data (ugidfw) or
	    they require extensive labeling (Biba, MLS).  This project idea
	    involves crafting a new OS security policy extension along the
	    lines of ugidfw, the file system firewall, but using path names
	    instead of existing file properties to manage protection.  This
	    requires careful thinking about what a file system path "is" in
	    the UNIX environment, as well as regarding what sorts of
	    policies would be useful.</p>
	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>Strong C programming skills.</li>
	    <li>Familiarity with OS security policies, including
	      discretionary and mandatory access control.</li>
	  </ul>
	</desc>
      </idea>

      <idea id="securityregression" class="soc">
	<title>Security regression tests</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>
FreeBSD is undergoing constant and active improvement to all of its critical
subsystems, from file systems to the network stack.  With any change, there
is a risk of introducing bugs or regressions.  The goal of this task is to
produce a security regression test suite, which encapsulates requirements
regarding system security properties and tests that they (still) hold.  Areas
to test include file system access control, privilege, authentication,
cryptography, process containment, and more.  There are some current tests
along these lines in the <a
href="http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/regression/">FreeBSD
regression test tree</a>, but they are both incomplete and inadequate.
New tests must be created; existing tests must be completed and updated.
</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Strong C programming skills.</li>
  <li>High tolerance for writing test code.</li>
  <li>High tolerance for reading API specifications.</li>
  <li>Rigorous and devious mindset.</li>
</ul>
	</desc>
      </idea>

      <idea id="auditparse" class="soc">
	<title>A New Audit Parsing API</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	  href="mailto:trustedbsd-audit@TrustedBSD.org">TrustedBSD audit
	  mailing list</a></p>

	<p>The current OpenBSM audit parsing API has a number of limitations,
	  not least that it can't handle little endian BSM records that may
	  come from Solaris x86 systems, in terms of ABI robustness in the
	  presence of new record types, ability to process trails generated
	  non-locally in terms of supporting uid/gid->name translation, and
	  in terms of incrementally processing a byte stream from, for
	  example, socket sources without using the C FILE API.</p>

	<p>This task would consider existing audit parsing APIs in the
	  industry, including POSIX.1e, relevant Open Group specs, and in-use
	  APIs on other systems such as Solaris, Linux, Windows NT, and
	  others, in order to first identify an existing candidate API or
	  design a new candidate API, then implement the API and adapt
	  existing audit applications to use it.  The task would also
	  document the API using man pages, create an audit parsing tutorial
	  document, create a test suites, and require interaction with the
	  OpenBSM and FreeBSD communities to identify audit parsing
	  requirements.</p>

	<p>If successful, the results of this work would be integrated into
	  OpenBSM, the open source BSD-licensed audit framework shipped with
	  FreeBSD and Mac OS X.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong C programming skills.</li>
	  <li>Past coursework or reading in the area of computer security.</li>
	</ul>
	</desc>
      </idea>

      <idea id="bsmconvert" class="soc">
	<title>NT/Linux to BSM Conversion Tool</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	  href="mailto:trustedbsd-audit@TrustedBSD.org">TrustedBSD audit
	  mailing list</a></p>

	<p>The BSM (Basic Security Framework) audit trail format is the de
	  facto industry standard for portable operating system audit trails,
	  being supported on Solaris, FreeBSD, and Mac OS X.  However, many
	  other audit trail formats exist that are less portable, including
	  audit trail formats local to Windows NT and Linux.</p>

	<p>This task would create BSD-licensed conversion tools to import
	  audit trails from other systems and convert them to BSM format so
	  that they can be inspected and managed using the OpenBSM tool set.
	  This would require the creation of BSD-licensed parsers for audit
	  trail formats of interest, designing and documenting a semantic
	  mapping to the BSM trail format, and writing conversion utilities
	  using the new parsers, semantic mapping, and BSM generation
	  routines in OpenBSM.  A key part of this work would be to
	  rigorously understand and document the mapping and its limitations
	  (for example, perhaps some Windows NT concepts can't be represented
	  in BSM in a natural way, such as larger SID than UID fields, which
	  is important information for anyone using BSM trails from NT
	  systems).  A test suite is also required.</p>

	<p>If successful, the results of this work would be integrated into
	  OpenBSM, the open source BSD-licensed audit framework shipped with
	  FreeBSD and Mac OS X.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong C programming skills.</li>
	  <li>Past coursework or reading in the area of computer security.</li>
	</ul>
	</desc>
      </idea>

      <idea id="appaudit" class="soc2009">
	<title>Application-Specific Audit Trails</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	  href="mailto:trustedbsd-audit@TrustedBSD.org">TrustedBSD audit
	  mailing list</a></p>

	<p>Currently, FreeBSD's audit trail support is a system-level
	  facility, intended to track system-level security events.  However,
	  as the affordability of computers has gone up, they are
	  increasingly single-application systems, and applications are
	  increasingly playing a role in the Trusted Code Base (TCB) of
	  larger integrated computing systems.  As such, it is desirable to
	  support reliable and secure auditing of application events that do
	  not correspond to the traditional TCB components, such as events
	  from databases, web servers, or virtual machines.  However, these
	  events need to be handled separately, as they have quite different
	  security and selection requirements.</p>

	<p>This task would extend the FreeBSD kernel's audit framework to
	  allow multiple concurrent audit trails to be maintained, reflecting
	  different "slices" of the system.  The base slice would be the
	  existing system audit trail, submitted to by the kernel itself, as
	  well as using the audit(2) system call, and stored in /var/audit.
	  New slices would be represented by named special devices in /dev,
	  with ownership and permissions reflecting their desired application
	  security properties; each slice would have its own audit worker and
	  queue, with its own pipe reliability properties and target trail
	  files.  This would require extending OpenBSM's auditd and libbsm to
	  support multiple trails as well.  Finally, two or more sample
	  applications would be modified to submit application-level
	  auditing, such as the authentication routines in Apache and
	  PostgreSQL.  This design would have several interesting properties,
	  not least that audit trails submitted by applications would be
	  protected from application tampering after submission, as the
	  kernel would mediate access using the TCB.  Analysis of potential
	  designs, security issues, documentation, and a test suite are
	  required.</p>

	<p>If successful, the results of this work would be integrated into
	  the FreeBSD kernel and OpenBSM.</p>

	<p><strong>Requirements</strong></p>
	<ul>
	  <li>Strong C programming skills.</li>
	  <li>Past coursework or reading in the area of computer security.</li>
	  <li>Past coursework in the area of operating system kernels.</li>
	</ul>
	</desc>
      </idea>

      <idea id="privmodel" class="soc">
	<title>New kernel privilege model</title>

	<desc>
	  <p><strong>Technical contact</strong>: <a
	    href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>

	  <p>FreeBSD uses a largely standard UNIX privilege model, granting
	    special OS rights to processes with an effective uid of 0.
	    Exceptional behavior lies in securelevel (restricting root based
	    on a global or per-jail level), Jail (limiting certain rights to
	    ensure safe containment for a jailed root user), and the ability
	    for the MAC Framework to augment privilege decisions.  However,
	    as of FreeBSD 7.0, privilege decisions internal to the kernel
	    have been made with respect to a large set of named privileges
	    (priv.h).  This project idea is to create a new privilege model,
	    similar perhaps to POSIX.1e or the Solaris privilege model,
	    allowing masks of privileges to be associated with process
	    credentials and managed with system calls.  Of particular
	    interest is supporting the assignment of privileges to users or
	    roles -- such as the right to bind low port numbers, use DTrace,
	    etc.
	  </p>
	</desc>
      </idea>

  </category>

  <category>
    <title>Userland / Installation Tools</title>

      <idea id="bsdelftools">
	<title>BSD-licensed ELF Tools</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:jkoshy@FreeBSD.org">Joseph Koshy</a>, <a
  href="mailto:kaiw@FreeBSD.org">Kai Wang</a></p>
<p>Create BSD-licensed versions of ELF processing tools (e.g., <strong>ld</strong>,
  <strong>dbx</strong>, <strong>as</strong> and others) using the ELF(3) and GELF(3)
  API set. Identify overlapping functions in those tools and
  create a library out of the common functions. Identify parts which can be
  generated by tools (e.g., machine code parser generators) to support our Tier-1
  and Tier-2 architectures.</p>
<p><strong>References</strong>:</p>
<ul>
  <li><a href="http://elftoolchain.sourceforge.net/">The ELF
    Toolchain Project on SourceForge.Net</a></li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
 <li>Knowledge of C.</li>
</ul>
	</desc>
      </idea>

      <idea id="bsdtexttools" class="soc2008">
	<title>BSD-licensed Text-Processing Tools</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:dds@FreeBSD.org">Diomidis Spinellis</a>,
  <a href="mailto:gabor@FreeBSD.org">G&aacute;bor K&ouml;vesd&aacute;n</a></p>
<p>Create/port BSD-licensed versions of one or more of the text processing
   tools that are currently missing from the FreeBSD distribution:
   <strong>sort</strong>,
   <strong>diff</strong>,
   <strong>groff/troff</strong> and the
   <strong>grep</strong> family.
   Licensed versions of some or all of these tools are already included
   in OpenBSD, so this task involves more porting and feature completion
   than development from scratch.
   Emphasis should be placed on performance, standards-compliance, and support
   for handling wide character sets.
</p>
<p>Regarding groff/troff, there exist the <a
   href="http://heirloom.sourceforge.net/doctools.html">OpenSolaris
   versions</a> at SourceForge which at least do not come with a viral license
   like the current GNU versions we use. Additionally this implementation has
   support for common vector fonts and unicode. If those utilities are
   option-compatible or not has to be analyzed. A port of this is already
   available as textproc/heirloom-doctools.  Alternatively, OpenBSD's
   <a href="http://mdocml.bsd.lv/">mdocml</a> can replace groff's mdoc
   functionality and may be sufficient for our purposes.
</p>
<p><strong>Requirements</strong>:</p>
<ul>
 <li>Knowledge of C.</li>
</ul>
	</desc>
      </idea>

      <idea id="noswitches">
	<title>Build options improvements</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a>, <a href="mailto:gbell72@rogers.com">Gardner Bell</a></p>
<p>The new "delete-old" and "delete-old-libs" target in /usr/src for 6.1 and
  -CURRENT should be extended to support the WITHOUT_* knobs, e.g.
  WITHOUT_RESCUE or WITHOUT_CRYPT, and delete files which are covered by those
  knobs.  Some switches have already been <a
  href="http://cvsweb.freebsd.org/src/tools/build/mk/OptionalObsoleteFiles.inc">covered</a>.
  You can view a list of all switches and what effect they have <a
  href="http://phk.freebsd.dk/misc/build_options/">here</a>.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Time to build and install the world several times.</li>
  <li>A way to determine which files were not touched by an installworld.</li>
</ul>
	</desc>
      </idea>

      <idea id="kde-freebsd-update" class="soc2007">
	<title>KDE front-ends to the freebsd-update(8)utility</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:cperciva@FreeBSD.org">Colin Percival</a></p>
<p>The freebsd-update(8) utility is used to fetch, install, and rollback
  binary updates to the FreeBSD base system.  A nice project would be to
  develop a graphical front-end for freebsd-update(8), using the QT toolkit.
  A GTK frontend was developed as part of GSoC 2007 and exists at <a
  href="http://developer.berlios.de/projects/facund">berlios</a>; the QT
  frontend could maybe share common functions/classes and design ideas.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Experience writing KDE applications</li>
</ul>
	</desc>
      </idea>

      <idea id="ipv6-userland" class="soc">
        <title>IPv6 User Land Cleanup</title>

        <desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:gnn@FreeBSD.org">George V. Neville-Neil</a></p>

<p>Many userland network utilities do not work correctly with IPv6.</p>
  <ul>
    <li>rpc.statd(8) is not IPv6 clean.</li>
    <li>rpc.rquotad(8) is not IPv6 clean.</li>
    <li>who(1) truncates IPv6 addresses in its output.</li>
  </ul>

<p>This project could also include a broader survey of other network
services in /usr/bin and /usr/sbin to make sure they're all IPv6
clean.</p>
        </desc>
      </idea>

      <idea id="lint">
	<title>lint(1) improvements from OpenBSD</title>

	<desc>
<p>OpenBSD has some improvements to lint(1) which may be beneficial to
  have.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
</ul>
	</desc>
      </idea>

      <idea id="libprocnet" class="soc2009">
	<title>Libprocstat and libnetstat</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>Create, similar to libmemstat, wrapper libraries to support monitoring and
  management applications to avoid direct use of kvm.  Three parts to the
  project: for each of the above, add kernel support to export data in a less
  ABI-sensitive way using sysctl, write a library to present the information
  in an extensible way to applications, and update applications to use the
  library instead of reaching directly into kernel memory / consuming sysctls.
  The goal is to allow the kernel implementation to change without breaking
  applications and requiring them to be recompiled, and to allow monitoring
  functions to be extended without breaking applications.  This should also
  facilitate writing new classes of monitoring and profiling tools.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of C.</li>
</ul>
	</desc>
      </idea>

      <idea id="ndmp">
	<title>NDMP data server</title>

	<desc>
<p><strong>URL</strong>: <a
  href="http://www.ndmp.org/">The NDMP Initiative</a></p>
<p>The NDMP initiative was launched to create an open
  standard protocol for network-based backup for network-attached storage.
  Major commercial storage systems come with a compliant service. This allows
  major commercial backup systems to backup such NAS devices. Including a NDMP
  disk server into FreeBSD would allow to play nice out of the box (modulo some
  configuring) regarding backups in a corporate environment.</p>
<ul>
  <li>Evaluate the existing revisions of the NDMP standard.</li>
  <li>Choose an appropriate revision (after checking of supported versions in
    commercial backup systems).</li>
  <li>Implement at least a NDMP data server.</li>
  <li>Bonus: implement a NDMP tape server (to allow attached tapes to be
    used).</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Access to a commercial backup system with NDMP support
    (mostly for interoperability testing; since a NDMPcopy
    application seems to be available, this is not a hard requirement).</li>
  <li>Good knowledge of a programming language which is included in
    the base system.</li>
  <li>Knowledge about UFS snapshots.</li>
</ul>
	</desc>
      </idea>

      <idea id="prebind">
	<title>Port prebind from OpenBSD</title>

	<desc>
<p>The OpenBSD prebind is a secure implementation of prelinking that
  is compatible with address space randomization.  Prelinking allows to
  speed up application startup when a lot of libraries are involved.
  This should show a noticeable effect with e.g. GNOME/KDE.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good C knowledge (reading and writing).</li>
</ul>
	</desc>
      </idea>

      <idea id="pacfile">
	<title>Proxy auto-config file support for libfetch</title>

	<desc>
<p>A proxy auto-config (PAC) file contains a JavaScript function
  "FindProxyForURL(url, host)" that determines which HTTP or SOCKS
  proxy, if any, to use to access a given URL.  In most application the
  file may be specified manually or discovered using the Web Proxy
  Autodiscovery Protocol.  Support for PAC files in libfetch would make
  fetch more versatile.</p>

<p>Supporting PAC files nominally requires a fairly complete JavaScript
  implementation.  There appear to be no BSD Licensed JavaScript
  implementations so one will likely need to be written.  A minimalist
  implementation of the language with commonly used constructs such as
  if/else, string comparison, and functions would be sufficient in many
  cases.</p>

<p><strong>References</strong>:</p>
<ul>
  <li><a href="http://en.wikipedia.org/wiki/Proxy_auto-config">Wikipedia
    Article on Proxy auto-config</a></li>
  <li><a href="http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html">Proxy
    Auto-Config File Format</a></li>
</ul>

<p><strong>Requirements</strong>:</p>
<ul>
	<li>Strong knowledge of secure C programming.</li>
</ul>
	</desc>
      </idea>

      <idea id="pxeinstaller">
	<title>PXE Installer</title>

	<desc>
<p>It would be great to have a bundled PXE installer.  This would allow one to
  boot an install server from a FreeSBIE live CD-ROM on one box, set the BIOS
  on subsequent boxes to PXE boot, and then have the rest happen by magic.
  This would be very helpful for installing cluster nodes, etc.</p>
<p><a href="mailto:m@FreeBSD.org">Markus Boelter</a> is <a
  href="http://wiki.freebsd.org/MarkusBoelter">working</a> on a bundled
  PXE installer as part of his BSDInstaller project within the Google Summer
  of Code 2006. The PXE Installer is working but some non-PXE related issues
  have to be solved before it can enter the tree.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good PXE knowledge.</li>
</ul>
	</desc>
      </idea>

      <idea id="regression">
	<title>Regression testing system</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a>, <a
  href="mailto:nik@FreeBSD.org">Nik Clayton</a></p>
<p>Nik has written a regression test infrastructure using Perl.  More of
  the regression tests should be made to work with libtap.</p>
<ul>
  <li>Many of the existing tests should be moved from using assert() to using
    ok() and friends from libtap.</li>
  <li>More regression tests should be written.</li>
</ul>
<p>Porting <a href="http://ltp.sf.net/">LTP</a> might also be a good idea.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good knowledge of scripting languages (Perl preferred).</li>
  <li>Good knowledge of software testing.</li>
</ul>
	</desc>
      </idea>

      <idea id="sysinstall">
	<title>Sysinstall</title>

	<desc>
<ul>
  <li>Ask for network configuration before install - so you do not have to
    configure the net twice.</li>
  <li>Make a guess of the timezone based upon country and keyboard.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Good C knowledge (reading and writing).</li>
  <li>No fear regarding "naturally grown" code.</li>
</ul>
	</desc>
      </idea>

      <idea id="taroutmode">
	<title>Tar output mode for installworld</title>

	<desc>
<p><strong>Technical contact</strong>: <a
  href="mailto:cperciva@FreeBSD.org">Colin Percival</a>, <a
  href="mailto:kientzle@FreeBSD.org">Tim Kientzle</a></p>

<p>Instead of installing using install, mkdir, mtree, etc, directly construct
  a tarball.  This would allow creating install distributions without root
  access, as setuid etc would never hit the local disk.  This would require
  some retrofitting of our installation mechanisms.</p>
<p>Bsdtar now (8-current, 20080101) has a feature that allows it to create
  a tar archive from a description provided in the form of an mtree file.
  This description can specify owner, permissions, and
  contents for each entry and does not require the files
  on disk to already have correct ownership.  This should
  make it possible to build a FreeBSD distribution as a
  non-root user. Talk to Tim Kientzle for details of the new bsdtar
  features and look at NetBSD, which has a similar facility, for
  ideas about how to proceed.</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>No fear regarding our installation system.</li>
</ul>
	</desc>
      </idea>

      <idea id="vi-utf8">
	<title>Unicode support in vi</title>

	<desc>
<p><strong>Technical info:</strong>: on J.R. Oldroyd's
    <a href="http://opal.com/jr/freebsd/unicode/">Unicode Support on
    FreeBSD</a> page</p>
<p>Many base system utilities grew multibyte support in 2004.  It would be
  nice to continue this trend by teaching vi(1) to display and edit
  documents in UTF-8 encoding.  The above referenced page contains info of
  what is needed to improve the Unicode support in vi(1).</p>
<p><strong>Requirements</strong>:</p>
<ul>
  <li>Knowledge of C.</li>
</ul>
	</desc>
      </idea>

      <idea id="cron-and-atrun">  
        <title>Improve cron(8) and atrun(8)</title>  

        <desc>  
  <p>Currently, cron(8) and atrun(8) are outdated in their implementation.
    Here are some directions for improvement:</p>
  <ul>
    <li>Update cron(8) to ISC cron with security fixes from OpenBSD.</li>
    <li>Integrate the atrun(8) functionality into cron(8),
      as it was done in NetBSD.</li>
  </ul>

  <p><strong>Requirements</strong>:</p>  
  <ul>
    <li>Strong knowledge of the C language and Unix API.</li>
  </ul>
        </desc>
     </idea> 

     <idea class="soc" id="wine">
       <title>Improve Wine support in FreeBSD</title>

       <desc><p><strong>Technical contact</strong>:  
        <a href="mailto:kris@pcbsd.com">Kris Moore</a></p>

       <p>In 2008, Tijl Coosemans did excellent work
         getting wine to a very usable point on FreeBSD. However,
         there are some issues which still need to be addressed at <a
         href="http://wiki.freebsd.org/Wine">http://wiki.freebsd.org/Wine</a>.
         This would be a big improvement for our desktop users.</p></desc>
     </idea>

      <idea id="bsnmp" class="soc">
	<title>BSNMP enhancements</title>

	<desc><p><strong>Technical contact</strong>:
	  <a href="mailto:syrinx@FreeBSD.org">Shteryana Shopova</a></p>

	<p>BSNMP is a portable SNMP framework consisting of a daemon,
	  modules and tools. It includes libraries that ease
	  the development of loadable modules for configuring and
	  monitoring various subsystems.
	  You can find more information about BSNMP
	  <a href="http://wiki.freebsd.org/Bsnmp">on the wiki</a>.
	  Some project ideas, but not limited to that list, can be found
	  <a href="http://wiki.freebsd.org/BsnmpTODO">here.</a>.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Knowledge of C.</li>
	  <li>Some familiarity with SNMP/MIBs desirable.</li>
	</ul>
	</desc>
      </idea>

      <idea class="soc" id="pthread-profile">
	<title>Userspace pthread mutex lock contention profiling and lock
	  order verification tool</title>

	<desc><p><strong>Technical contact</strong>: <a
	  href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>

	<p>This task would create an extension to the threading library
	  that would allow application developers to measure and locate lock
	  ordering and lock contention problems within their application.
	  Such a tool is invaluable in debugging application deadlocks and
	  creating high-performance multithreaded software.  Existing lock
	  ordering and profiling tools exist in the FreeBSD kernel, and
	  could be used as the model for the userspace implementation.  We
	  would recommend beginning with profiling due to its immediate
	  usefulness in optimizing performance, and to allow improvements
	  in kernel scheduling to better manage user application lock
	  contention.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	  <li>Strong knowledge of C.</li>
	  <li>Threading experience.</li>
	  <li>Strong debugging skills.</li>
	</ul>
	</desc>
      </idea>

      <idea class="soc" id="freebsd-gnome-networkmanager">
	<title>FreeBSD port of NetworkManager</title>

	<desc><p><strong>Technical contact</strong>: <a
	  href="mailto:marcus@FreeBSD.org">Joe Marcus Clarke</a></p>

    	  <p>This task is to port
	    <a href="http://www.gnome.org/projects/NetworkManager/">
	      NetworkManager</a> to FreeBSD.  Porting NetworkManager
	    will also require some core userland changes to FreeBSD,
	    especially to ifconfig.</p>

	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>C programming skills</li>
	    <li>Knowledge of the FreeBSD net80211 wireless stack</li>
          </ul>
	</desc>
      </idea>

      <idea class="soc" id="freebsd-gnome-systemtools">
	<title>Fix FreeBSD support in GNOME's system-tools-backends</title>

	<desc><p><strong>Technical contact</strong>: <a
	  href="mailto:marcus@FreeBSD.org">Joe Marcus Clarke</a></p>

  	  <p>This task is to fix FreeBSD support in
	      sysutils/system-tools-backends.</p>

	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>Perl programming skills</li>
	    <li>Knowledge of the FreeBSD system configuration</li>
          </ul>
	</desc>
      </idea>

      <idea class="soc" id="freebsd-gnome-hal">
	  <title>Extend hal support on FreeBSD</title>

	<desc><p><strong>Technical contact</strong>: <a
	  href="mailto:marcus@FreeBSD.org">Joe Marcus Clarke</a></p>

  	  <p>This task is to add hal support for some additional
	    subsystems.  In particular FreeBSD is lacking support for the
	    ieee1394 (i.e. Firewire), bluetooth, and printer.  Adding
	    support for these subsystems will require changes to the
	    FreeBSD kernel.  Those interested should use the latest
	    <a href="http://www.marcuscom.com/hal-spec/hal-spec.html">
	      HAL Specification</a> as a guide.</p>

	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>C programming skills</li>
	    <li>Knowledge of the FreeBSD system internals</li>
          </ul>
	</desc>
      </idea>

      <idea class="soc" id="freebsd-amd64-gcc-m32">
	  <title>Finish support for compilation of i386 binaries on amd64</title>

	<desc><p><strong>Technical contact</strong>: <a
	  href="mailto:kib@FreeBSD.org">Konstantin Belousov</a></p>

  	  <p>The FreeBSD binutils and gcc on amd64 are capable to build
	    32bit binaries. What we miss is the proper includes for
	    i386 accessed when #include &lt;machine/some.h&gt; is used,
	    for the -m32 invocation of the cc. Project would provide
	    an installation of both amd64 and i386 includes in
	    non-conflicting way, and changes to the gcc to select
	    proper location for machine/ based on the compilation target
	    architecture.</p>

	  <p><strong>Requirements</strong>:</p>
	  <ul>
	    <li>C and shell programming skills</li>
	    <li>Knowledge of the FreeBSD build and installation infrastructure</li>
	    <li>Some knowledge of the gcc internals</li>
          </ul>
	</desc>
      </idea>

    <idea id="jailinit" class="soc">
      <title>Jail init and management</title>
      <desc>
	<p><strong>Technical contact</strong>: <a
	  href="mailto:bz@FreeBSD.org">Bjoern Zeeb</a>, <a
	  href="mailto:imp@FreeBSD.org">Warner Losh</a>, <a
	  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>

	<p>FreeBSD's jail(8) facility provides lightweight operating system
	  virtualization; with the addition of experimental virtual network
	  stacks, ISPs are able to efficiently host thousands of FreeBSD
	  instances on a single machine.  This task improves FreeBSD's
	  userspace management of jails by introducing jailinit(8), an
	  enhancement to the init(8) utility responsible for starting up and
	  shutting down the operating system.  Currently, jails are started
	  by executing their /etc/rc script directly using jail(8); in the
	  proposed new world order, init(8) would have a jail start mode,
	  and would continue running throughout the lifetime of the jail to
	  manage services and eventually shut down the jail.  This might
	  require minor kernel changes in order to let jailinit perform some
	  of the same functions for jails as it does for normal userspace.
	  jailinit could also be responsible for setting up and managing
	  console logging, launching tty-attached services such as getty
	  within a jail, and other jail properties.</p>

	<p><strong>Requirements</strong></p>
	<ul>
	  <li>C and shell programming skills</li>
	  <li>Interest in virtualization</li>
	</ul>
      </desc>
    </idea>

  </category>
</ideas>
