os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/en/projects/ideas/index.sgml
Joel Dahl f0bc03c025 - Fix minor nits in the ZFS entry. [1] 
-  Move libumem to the correct (alphabetically) place. [2]

Requested by:	netchild [1]
Discussed with:	keramida [2]
2006-06-04 12:36:39 +00:00

1342 lines
53 KiB
Text
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD: www/en/projects/ideas/index.sgml,v 1.47 2006/06/02 20:40:57 joel Exp $">
<!ENTITY title "FreeBSD list of projects and ideas for volunteers">
<!ENTITY % navincludes SYSTEM "../../includes.navdevelopers.sgml"> %navincludes;
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
<!ENTITY man.vi.1 "<a href='http://www.FreeBSD.org/cgi/man.cgi?query=vi&amp;sektion=1'>vi(1)</a>">
<!ENTITY man.wi.4 "<a href='http://www.FreeBSD.org/cgi/man.cgi?query=wi&amp;sektion=4'>wi(4)</a>">
]>
<html>
&header;
<h2>Introduction</h2>
<p>The FreeBSD project has hundreds of active developers spread all over the
world, and many of them have their own parts of the source-tree that they
work on. However, there are always a lot of new interesting projects and
ideas that needs to be investigated and evaluated, and this is where the
FreeBSD project relies on heroic efforts from volunteers. The following
list of possible projects is in no way complete, but it should serve as a
nice starting point for volunteers who would like to become committers in
the future.</p>
<p>Please note that we cannot guarantee that your work will be included in the
FreeBSD source tree. This is because people tend to disagree about specifics
in the implementation of new features or functionality. However, if you can
find a developer who is interested in your work, and you can get him or her
to review it, then you are pretty far on your way to get your code into the
FreeBSD source tree.</p>
<p>If you have any non-technical questions about this list, please contact <a
href="mailto:netchild@FreeBSD.org">&a.netchild;</a> and <a
href="mailto:joel@FreeBSD.org">&a.joel;</a>. Technical questions
should be directed to the Technical contact for each project, or to the <a
href="mailto:hackers@FreeBSD.org">hackers mailinglist</a>.</p>
<hr>
<h3>File System</h3>
<ul>
<li><a href="#p-autofs">AutoFS</a></li>
<li><a href="#p-extenddump">Extend UFS2 dump/restore support</a></li>
<li><a href="#p-magicsymlinks">Magic Symlinks</a></li>
<li><a href="#p-mdfs">MDFS lockups</a></li>
<li><a href="#p-tmpfs">TMPFS</a></li>
<li><a href="#p-zfs">ZFS</a></li>
</ul>
<h3>Kernel</h3>
<ul>
<li><a href="#p-sync4front">4Front Technologies OSS v4 API</a></li>
<li><a href="#p-cachesparc64">Cache detection support for sparc64</a></li>
<li><a href="#p-camlocking">CAM layer locking</a></li>
<li><a href="#p-cpuusage">CPU usage display in top</a></li>
<li><a href="#p-docsysctl">Document all sysctls</a></li>
<li><a href="#p-docsound">Document the sound subsystem</a></li>
<li><a href="#p-dtrace">DTrace</a></li>
<li><a href="#p-assembler">DWARF2 call frame information</a></li>
<li><a href="#p-modrefcnt">Dynamic module references</a></li>
<li><a href="#p-ktrace">Extend ktrace/kdump output</a></li>
<li><a href="#p-memcpy">FPU subsystem overhaul</a></li>
<li><a href="#p-geninput">Generic input device layer</a></li>
<li><a href="#p-hda">High Definition Audio (HDA) support</a></li>
<li><a href="#p-powerd">Implement and profile algorithms for powerd</a></li>
<li><a href="#p-iscsi">iSCSI</a></li>
<li><a href="#p-amd64linux">Linuxulator with native amd64 support</a></li>
<li><a href="#p-pcihotplug">PCI-Hotplug support</a></li>
<li><a href="#p-psched">Pluggable Disk Scheduler</a></li>
<li><a href="#p-processcheck">Process checkpointing</a></li>
<li><a href="#p-trussprocfs">Remove procfs dependency from truss</a></li>
<li><a href="#p-syncer">Rewrite the in-kernel file system syncer</a></li>
<li><a href="#p-suspend">Suspend to disk</a></li>
<li><a href="#p-bootcode">Sync FreeBSD i386 boot code with DragonFly</a></li>
<li><a href="#p-usbnetbsd">Sync USB code with NetBSD</a></li>
<li><a href="#p-sysmod">Syscons modularization</a></li>
<li><a href="#p-updatelinux">Update the Linuxulator</a></li>
</ul>
<h3>Networking</h3>
<ul>
<li><a href="#p-csup">csup improvements</a></li>
<li><a href="#p-flightmode">Flight mode for the loader</a></li>
<li><a href="#p-iapp">IAPP preauthentication in hostapd</a></li>
<li><a href="#p-nfslockdsemantics">NFS Lockd (improve semantics)</a></li>
<li><a href="#p-nfslockdkernel">NFS Lockd (kernel implementation)</a></li>
<li><a href="#p-suptundaemon">Super tunnel daemon</a></li>
<li><a href="#p-wi">Update wi</a></li>
<li><a href="#p-wpa2preauth">WPA2 preauthentication in hostapd</a></li>
<li><a href="#p-zeroconf">Zeroconf</a></li>
</ul>
<h3>Ports</h3>
<h3>Security</h3>
<h3>Userland / Installation Tools</h3>
<ul>
<li><a href="#p-noswitches">Build options improvements</a></li>
<li><a href="#p-impnssldap">Import NSS LDAP</a></li>
<li><a href="#p-hesiodlibc">Move HESIOD to a NSS module</a></li>
<li><a href="#p-nisyplibc">Move NIS/YP to a NSS module</a></li>
<li><a href="#p-multibyte">Multibyte collation support</a></li>
<li><a href="#p-ndmp">NDMP data server</a></li>
<li><a href="#p-performancetracking">Performance tracking</a></li>
<li><a href="#p-libumem">Port libumem to FreeBSD</a></li>
<li><a href="#p-pxeinstaller">PXE Installer</a></li>
<li><a href="#p-regression">Regression testing system</a></li>
<li><a href="#p-rfc3442">RFC3442 support</a></li>
<li><a href="#p-sysinstall">Sysinstall</a></li>
<li><a href="#p-vi-utf8">Unicode support in vi</a></li>
</ul>
<h3>Additional Information</h3>
<ul>
<li><a href="#p-projects">Projects at FreeBSD.org</a></li>
<li><a href="#p-tc">Technical contacts</a></li>
</ul>
<hr>
<!------------------------------------------------------------------>
<!- File System ->
<!------------------------------------------------------------------>
<a name="p-autofs"></a>
<h2>AutoFS</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
<p>Create the autofs file system from a specification.
Kernel transport and interaction with the "amd" automounter
needs to be completed.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of file systems and network file systems.</li>
<li>Good knowledge of C.</li>
</ul>
<hr>
<a name="p-magicsymlinks"></a>
<h2>Magic Symlinks</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:jwd@FreeBSD.org">&a.jwd;</a></p>
<p><strong>Patches</strong>: <a
href="http://people.FreeBSD.org/~jwd/magiclinks.tgz">http://people.FreeBSD.org/~jwd/magiclinks.tgz</a></p>
<p>Experimental patches exist against 4-STABLE, though the DragonFly
implementation using the setvar utility should be examined (interesting
files in the DragonFly CVS: sys/kern/init_sysent.c, sys/kern/kern_varsym.c,
sys/kern/syscalls.c, sys/kern/syscalls.master, sys/kern/vfs_lookup.c,
sys/sys/syscall-hide.h, sys/sys/syscall.h, sys/sys/syscall.mk,
sys/sys/sysproto.h, sys/sys/sysunion.h, bin/varsym/varsym.1,
bin/varsym/varsym.c).</p>
<p><a href="mailto:bu7cher@yandex.ru">Andrey V. Elsukov</a> has begun porting
this to FreeBSD, and some initial patches for CURRENT can be found <a
href="http://butcher.heavennet.ru/patches/kernel/varsym/">here</a>.
There is also some on-going development in Perforce.</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>Some file system knowledge.</li>
</ul>
<hr>
<a name="p-mdfs"></a>
<h2>MDFS lockups</h2>
<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>
<hr>
<a name="p-tmpfs"></a>
<h2>TMPFS</h2>
<p>At the moment FreeBSD includes a memory-based file system called mfs.
mfs is just an implementation of the regular ffs - designed for
persistent storage - on top of the (volatile) virtual memory system.
This means that it uses the same data structures as the on-disk
implementation, rendering less than optimal performance and memory
usage. With tmpfs, FreeBSD would gain a memory file system which uses
less memory and is faster.</p>
<p><strong>Goals</strong>:</p>
<ul>
<li>Port the tmpfs file system.</li>
<li>Adopt the documentation (including the file system how-to)</li>
</ul>
<p><a href="mailto:rohitj@purpe.com">Rohit Jalan</a> has begun <a
href="http://lists.freebsd.org/pipermail/freebsd-hackers/2006-February/015575.html">porting</a>
the NetBSD tmpfs to FreeBSD. More information about the current status and
progress is available <a href="http://download.purpe.com/tmpfs">here</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>A little bit of knowledge of the VFS subsystem.</li>
</ul>
<hr>
<a name="p-extenddump"></a>
<h2>Extend UFS2 dump/restore support for UFS2</h2>
<p>The UFS2 file system in FreeBSD supports extended attributes. Extended
attributes are meta-data associated with vnodes representing files and
directories. Unfortunately dump and restore do not backup or restore
such attributes. People interested in this should contact <a
href="mailto:mckusick@FreeBSD.org">&a.mckusick;</a>.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C programming.</li>
<li>Basic understanding of backup/restore procedures.</li>
</ul>
<hr>
<a name="p-zfs"></a>
<h2>ZFS</h2>
<p><strong>References</strong>: <a
href="http://www.opensolaris.org/os/community/zfs/whatis/">What is ZFS?</a>,
<a
href="http://www.opensolaris.org/os/community/zfs/porting/">Porting
ZFS</a><p>
<p>OpenSolaris&#153; gained support for a new file system called ZFS (Zettabyte
File System) as of build 27a. ZFS is a new approach to file
system design and data management, and includes several interesting features
such as transactional semantics, snapshots and good scalability. Porting ZFS
to FreeBSD is higly encouraged, but should be considered a difficult
task since the current implementation of ZFS is very
Solaris-specific.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong C knowledge.</li>
<li>Strong knowledge about file systems.</li>
<li>Knowledge about the FreeBSD VFS subsystem.</li>
</ul>
<hr>
<!------------------------------------------------------------------>
<!- Kernel ->
<!------------------------------------------------------------------>
<a name="p-sync4front"></a>
<h2>4Front Technologies OSS v4 API</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
<p><strong>References</strong>: <a href="http://www.opensound.com/">4Front
Technologies</a></p>
<p>4Front Technologies will go live with an improved OSS API in the near future
and we are discussing syncing with this API at the freebsd-multimedia mailing
list. 4Front Technologies offered assistance. A volunteer would have
to:</p>
<ul>
<li>Add the necessary interfaces.</li>
<li>Add appropriate code to the sound subsystem/drivers where possible.</li>
<li>Document the work (manual pages, maybe sound subsystem chapter in the
FreeBSD Architecture Handbook, maybe extending the example driver). This
part overlaps with the sound subsystem documentation project. Maybe
4Front is willing to donate parts of their documentation. Coordination
regarding this is required.</li>
<li>Use the improved API in our userland programs where it is
beneficial.</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>At least one supported sound card.</li>
</ul>
<hr>
<a name="p-cachesparc64"></a>
<h2>Cache detection support for sparc64</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:netchild@FreeBSD.org">&a.netchild;</a> (Page coloring)</p>
<p><strong>Mailing list</strong>: <a
href="mailto:freebsd-sparc64@FreeBSD.org">freebsd-sparc64@FreeBSD.org</a></p>
<p>The current page coloring algorithm in the VM does auto tuning of the
number of colors based upon cache size and associativity. On sparc64
the corresponding variables are not set. The goal of this entry is to
detect the cache size and associativity (this information may already
be available, or at least not much code has to be written) and set the
corresponding variables.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
<li>A sparc64 system to test/debug with.</li>
<li></li>
</ul>
<hr>
<a name="p-camlocking"></a>
<h2>CAM layer locking</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:scottl@FreeBSD.org">&a.scottl;</a></p>
<p>&a.scottl; has been working on this for a while, and he has patches in
Perforce.</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 about SCSI.</li>
<li>A good understanding of the FreeBSD locking methods.</li>
</ul>
<hr>
<a name="p-cpuusage"></a>
<h2>CPU usage display in top</h2>
<p>The current kernel statistics do not know how to calculate the CPU usage
of threaded processes. A volunteer has to understand the current statistics
model, design a new statistics model and implement it.</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 the FreeBSD SMP system.</li>
</ul>
<hr>
<a name="p-docsysctl"></a>
<h2>Document all sysctls</h2>
<p><strong>Technical contacts</strong>: <a
href="mailto:mat@FreeBSD.org">&a.mat;</a>, <a
href="mailto:brd@FreeBSD.org">&a.brd;</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. &a.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>
<hr>
<a name="p-docsound"></a>
<h2>Document the sound subsystem</h2>
<p><strong>Technical contacts</strong>: <a
href="mailto:netchild@FreeBSD.org">&a.netchild;</a>, <a
href="mailto:ariff@FreeBSD.org">&a.ariff;</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>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Documentation writing skills.</li>
</ul>
<hr>
<a name="p-dtrace"></a>
<h2>DTrace</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:jb@FreeBSD.org">John Birrell</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.</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 the FreeBSD kernel.</li>
</ul>
<hr>
<a name="p-assembler"></a>
<h2>DWARF2 call frame information</h2>
<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>
<hr>
<a name="p-modrefcnt"></a>
<h2>Dynamic module references</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:sam@FreeBSD.org">&a.sam;</a></p>
<p>Kernel modules may have dynamic references created during operation.
For example net80211 key entries reference functions in the crypto module
that implements the key's cipher. Presently there is no standard mechanism
for expressing this dependency so that module unloading is disallowed;
instead modules must track references and implement their own semantics.
This task is to define and implement a general mechanism for tracking
these references and use them in handling module unload requests.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Kernel awareness.</li>
</ul>
<hr>
<a name="p-ktrace"></a>
<h2>Extend ktrace/kdump output</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:netchild@FreeBSD.org">&a.netchild;</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><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>
<hr>
<a name="p-memcpy"></a>
<h2>FPU subsystem overhaul</h2>
<p>Port DragonFly's MMX/XMM optimized memcpy/bcopy/bzero/copyin/copyout code
(this includes an FPU subsystem overhaul). Interesting files in the
DragonFly CVS are sys/i386/gnu/fpemul/fpu_system.h,
sys/i386/i386/bcopy.s, sys/i386/i386/genassym.c, sys/i386/i386/globals.s,
sys/i386/i386/machdep.c, sys/i386/i386/math_emu.h,
sys/i386/i386/mp_machdep.c, sys/i386/i386/pmap.c, sys/i386/i386/support.s,
sys/i386/i386/swtch.s, sys/i386/i386/trap.c, sys/i386/i386/vm86bios.s,
sys/i386/i386/vm_machdep.c, sys/i386/include/asmacros.h,
sys/i386/include/globaldata.h, sys/i386/include/md_var.h,
sys/i386/include/npx.h, sys/i386/include/pcb.h, sys/i386/include/thread.h
sys/i386/isa/npx.c, sys/i386/i386/bcopy.s and sys/i386/i386/bzero.s. A more
detailed writeup can be found in <a
href="http://www.leidinger.net/FreeBSD/dfly_fpu.txt.bz2">this compressed
file</a>. This includes a mail from Matthew Dillon with suggestions on how
to do this in FreeBSD (including a small benchmark which shows 35%-55% speed
improvement for at least those benchmarks).</p>
<p><a href="mailto:rookie@gufi.org">Attilio Rao</a> has almost <a
href="http://lists.freebsd.org/pipermail/freebsd-hackers/2006-May/016702.html">completed</a>
this work, but he would like to receive more feedback.</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 at least i386/MMX/XMM assembly.</li>
<li>A good understanding of the FreeBSD SMP system.</li>
<li>Roughly 6 weeks of free time.</li>
</ul>
<hr>
<a name="p-geninput"></a>
<h2>Generic input device layer</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:philip@FreeBSD.org">&a.philip;</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 (&a.philip; has some work-in-progress regarding pointer
devices and touchscreen support, but not enough time to also cover keyboard
support or other generic features).</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>
<hr>
<a name="p-hda"></a>
<h2>High Definition Audio (HDA) support</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:freebsd-multimedia@FreeBSD.org">freebsd-multimedia@FreeBSD.org</a>
(mailing list)</p>
<p><strong>URL</strong>: <a href="http://www.intel.com/standards/hdaudio/">HDA
Specification</a></p>
<ul>
<li>Have a look at the specification.</li>
<li>Implement HDA support.</li>
</ul>
<p>Some work has been done, but progress is slow. More manpower is needed. <a
href="mailto:<sepotvin@videotron.ca">Stephane E. Potvin</a> has <a
href="http://lists.freebsd.org/pipermail/freebsd-multimedia/2006-May/004248.html">begun</a>
implementing HDA support to our sound system and a patch is available <a
href="http://www.leidinger.net/FreeBSD/hdac_20060525.tbz">here</a>. This
is very experimental, and should not be considered stable code.</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>HDA-based sound card.</li>
</ul>
<hr>
<a name="p-powerd"></a>
<h2>Implement and profile algorithms for powerd</h2>
<p><strong>Technical contacts</strong>: <a
href="mailto:njl@FreeBSD.org">&a.njl;</a>, <a
href="mailto:bruno@FreeBSD.org">&a.bruno;</a></p>
<p>Implement a range of predictive algorithms (and perhaps design your own)
and profile them for power usage and performance loss. The best
algorithm will save the most power while losing the least performance. This
has been discussed on the <a href="mailto:acpi@FreeBSD.org">ACPI</a> mailing
list and &a.bruno; has some early patches.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Basic C knowledge.</li>
<li>Laptop supported by cpufreq(4).</li>
</ul>
<hr>
<a name="p-iscsi"></a>
<h2>iSCSI</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:danny@cs.huji.ac.il">Danny Braniss</a></p>
<p>Danny Braniss has been working on an iSCSI stack for FreeBSD for some time
now. His work is in Perforce, and he has posted several patch sets
and had numerous discussions on the mailing lists.</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 about (i)SCSI/CAM.</li>
</ul>
<hr>
<a name="p-amd64linux"></a>
<h2>Linuxulator with native amd64 support</h2>
<p>FreeBSD provides Linux binary compatibility through a Linux system call
table that is invoked when Linux ELF binaries are executed. The
implementation on amd64 machines only provides support for 32bit (x86)
executables. This needs to be coordinated with the <a
href="mailto:emulation@FreeBSD.org">emulation mailinglist</a> regarding
the userland part of the linuxulator.</p>
<ul>
<li>Determine a way how to distinguish between 32 bit and 64 bit applications
when entering a system call.</li>
<li>Design and implement 64 bit support while keeping 32 bit support.</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 how to do a clean room implementation of GPL'ed
code (no copy & paste!).</li>
</ul>
<hr>
<a name="p-pcihotplug"></a>
<h2>PCI-Hotplug support</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:bms@FreeBSD.org">&a.bms;</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>
<hr>
<a name="p-psched"></a>
<h2>Pluggable Disk Scheduler</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:s223560@studenti.ing.unipi.it">Emiliano Mennucci</a></p>
<p><strong>References</strong>: <a
href="http://wikitest.freebsd.org/moin.cgi/Hybrid">The Pluggable Disk
Schedulers SoC project</a>, <a
href="http://www.happyemi.org/hybrid/">Patches</a></p>
<p>Our "Pluggable Disk Schedulers" SoC 2005 project resulted in code which
solved the problem where large sequential I/O requests, or certain
access patterns from one or a few processes, might almost completely
starve other processes. It is available as a patch for RELENG_4 and
RELENG_5. Unfortunately the code in FreeBSD-current (and RELENG_6)
changed too much, so that the patches can not be committed. The goal
of this project is to port the pluggable disk schedulers to the GEOM
framework.</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>
<hr>
<a name="p-processcheck"></a>
<h2>Process checkpointing</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:bruno@FreeBSD.org">&a.bruno;</a></p>
<p>Process checkpointing allows to migrate some processes to other machines or
to let some processes "survive" a reboot (subject to some constraints).
Interesting files in the DragonFly CVS repository are sys/sys/ckpt.h,
sys/checkpt/* and sys/kern/imgact_elf.c.</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>
<hr>
<a name="p-trussprocfs"></a>
<h2>Remove procfs dependency from truss</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:mux@FreeBSD.org">&a.mux;</a></p>
<p>Someone needs to finish the support for PT_SYSCALL in the ptrace()
subsystem, and add support for another ptrace() command that will replace
the PIOCWAIT and PIOCSTATUS ioctls of procfs (should probably be named
PT_WAIT), in order for truss(1) to be able to work without procfs(5).</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>C knowledge.</li>
<li>Understanding of kernel debugging interfaces.</li>
</ul>
<hr>
<a name="p-syncer"></a>
<h2>Rewrite the in-kernel file system syncer</h2>
<p><strong>References</strong>: <a
href="http://lists.freebsd.org/mailman/htdig/freebsd-arch/2005-March/003594.html">mail
#1</a>, <a
href="http://lists.freebsd.org/mailman/htdig/freebsd-performance/2005-February/001083.html">mail
#2</a></p>
<p><strong>Goals</strong>:</p>
<ul>
<li>Change the syncer so it can sync out to multiple physical devices
simultaneously.</li>
<li>Only write out up to X megabytes of data, remember where it
left off, and then proceed to the next dirty file (OpenBSD and
NetBSD already do this).</li>
<li>Replace the write_behind code with something (detect the existence
of a large amount of sequential dirty data and kick another thread
to flush it out synchronously, instead of doing it itself
asynchronously) integrated into the syncer (the data set size could
perhaps be increased from 64KB to 1MB).</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>Some understanding of the VM system / buffer cache.</li>
</ul>
<hr>
<a name="p-suspend"></a>
<h2>Suspend to disk</h2>
<p><strong>Technical contacts</strong>: <a
href="mailto:njl@FreeBSD.org">&a.njl;</a>, <a
href="mailto:bruno@FreeBSD.org">&a.bruno;</a></p>
<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>
<hr>
<a name="p-bootcode"></a>
<h2>Sync FreeBSD i386 boot code with DragonFly</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:jhb@FreeBSD.org">&a.jhb;</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>
<hr>
<a name="p-usbnetbsd"></a>
<h2>Sync USB code with NetBSD</h2>
<p><strong>Mailing list</strong>: <a
href="mailto:freebsd-usb@FreeBSD.org">freebsd-usb@FreeBSD.org</a></p>
<p>There are various improvements and fixes to the USB code in NetBSD
which have not found their way into FreeBSD yet.</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>Various USB devices and/or energy to let people on the USB mailing list
test patches and listen to bug reports regarding those tests.</li>
</ul>
<hr>
<a name="p-sysmod"></a>
<h2>Syscons modularization</h2>
<p>Separate the syscons code into distinct parts for input, output,
console handling (switching, screen savers etc.) and terminal
emulation. Also implement vt100 and vt220 emulation to supplement
the existing SCO emulation. Add a gettytab(5) capability for
specifying the terminal emulation, and add entries to /etc/gettytab
for the alternative emulations.</p>
<p>Optionally implement xterm emulation. The top line of the screen
should serve as a title bar, displaying the title set with the \e]0;
escape sequence as well as the vty number.</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 text terminals and terminal emulation.</li>
</ul>
<hr>
<a name="p-updatelinux"></a>
<h2>Update the Linuxulator</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:cracauer@FreeBSD.org">&a.cracauer;</a></p>
<p>FreeBSD provides Linux binary compatibility through a Linux system call
table that is invoked when Linux ELF binaries are executed. This
implementation should be compared with an up-to-date Linux kernel so that
important missing syscalls can be added to ensure that all mainstream
applications continue to work on FreeBSD.</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 closely observe system call tracing to spot subtle differences
in the behavior of certain calls.</li>
<li>A good understanding of how to do a clean room implementation of GPL'ed
code (no copy & paste!).</li>
</ul>
<hr>
<!------------------------------------------------------------------>
<!- Networking ->
<!------------------------------------------------------------------>
<a name="p-csup"></a>
<h2>csup improvements</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:mux@FreeBSD.org">&a.mux;</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>&a.mux; is working on a rewrite of CVSup in C, called csup, and he has
imported csup into the FreeBSD base system. It should be ready for use in a
stable environment, but there are however still several missing features.
The following list should be a good starting point:</p>
<ul>
<li>Add support for authentication.</li>
<li>Add support for shell commands sent by the server.</li>
<li>Add missing support for various CVSup options: -D, -a (requires
authentication support), -e and -E (requires shell commands support)
and the destDir parameter.</li>
<li>Add support for CVS mode. This is important for developers, since this
mode sends the actual RCS files themselves. This is very useful
for storing a full copy of the CVS repository on the client machine.</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>
<hr>
<a name="p-flightmode"></a>
<h2>Flight mode for the loader</h2>
<p>Not every airline allows to use radio transmitters like WLAN-NIC's in
airplanes (yet). The goal of this entry is to provide an entry in the
loader which prohibits drivers for devices which transmit radio signals
to attach to the device. One way of providing this functionality would
be to add a menu entry to the loader which sets a "flight mode" loader
tunable which would have to be queried by every driver which is able to
transmit radio signals to decide if the normal operation is allowed or
if the device has to be disabled. The loader-menu should be able to
detect this tunable in loader.conf and indicate which way of booting is
the current default (in case the user adds it there to be on the safe
side in the airplane).</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C (changing the drivers to respect the tunable).</li>
<li>Knowledge of forth (changing the loader-menu).</li>
</ul>
<hr>
<a name="p-iapp"></a>
<h2>IAPP preauthentication in hostapd</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:sam@FreeBSD.org">&a.sam;</a></p>
<p>IAPP is the Inter-Access Point Protocol, a protocol by which
cooperating access points communicate about associated wireless
stations. 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 IAPP 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>Wireless network setup.</li>
</ul>
<hr>
<a name="p-nfslockdsemantics"></a>
<h2>NFS Lockd (improve semantics)</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
<ul>
<li>Improve the semantics of the NFS lockd in FreeBSD. Apple has made
certain enhancements that can be leveraged in our code base.</li>
<li>Implement state recovery in the lockd.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
</ul>
<hr>
<a name="p-nfslockdkernel"></a>
<h2>NFS Lockd (kernel implementation)</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
<p>Moving the lockd implementation into the kernel provides several key
performance and semantic improvements.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Good understanding of NFS.</li>
<li>Good understanding of locking.</li>
<li>Good understanding of RPC.</li>
<li>Good understanding of kernel level networking.</li>
</ul>
<hr>
<a name="p-suptundaemon"></a>
<h2>Super tunnel daemon</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:phk@FreeBSD.org">&a.phk;</a></p>
<p>IP can be tunneled over IP, UDP, TCP, SSH, DNS, HTTP and many other
protocols, and this means that it is often possible to get a
connection out through a firewall, but each of these encapsulations
require prior setup of a specific program for each encapsulation, and
the user must experiment to decide which one to use at any one time.
The super tunnel daemon should implement pluggable encapsulations and
make it automatically select the most efficient encapsulation that
works at any one time. The user should not notice transitions from one
encapsulation to another, apart from maybe a small delay.</p>
<p>Wanted features (not sorted or prioritized):</p>
<ul>
<li>Autodetection of the environment (DHCP, DNS, routing, ...) in a
non-offensive way (no global portscans allowed; asking via DHCP,
zeroconf or similar technologies is ok) as far as possible.</li>
<li>Plugin architecture for easy addition of further encapsulations.</li>
<li>Failover from one encapsulation to another.</li>
<li>Distinct configuration files for encapsulations which need to be
configured (e.g. proxy, authentication, ...).</li>
<li>Possibility to disable installed encapsulations.</li>
<li>Print/log hints for protocols which require some configuration,
e.g. telling the user to use keys and perhaps the ssh-agent for ssh.</li>
<li>Configurable additional plugin directories (for plugins installed
via the ports collection).</li>
<li>Log how it is able to tunnel the traffic (this also makes it useful
for finding unwanted holes in the configuration of a firewall).</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Good knowledge about networks.</li>
</ul>
<hr>
<a name="p-wi"></a>
<h2>Update wi</h2>
<p>Many new and useful features (e.g. crypto protocols like WPA) of the WLAN
infrastructure in the kernel are not used in &man.wi.4;. While &man.wi.4;
cards are old and can not compete with recent wireless cards, they are still
in use in a lot of places. The goal of this item is to examine the WLAN
infrastructure and other WLAN drivers in the tree for nice features and
port/use them in the &man.wi.4; driver.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
<li>No fear of undocumented parts of the kernel.</li>
<li>One &man.wi.4; card and one other wireless device to test against.</li>
</ul>
<hr>
<a name="p-wpa2preauth"></a>
<h2>WPA2 preauthentication in hostapd</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:sam@FreeBSD.org">&a.sam;</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>
<hr>
<a name="p-zeroconf"></a>
<h2>Zeroconf</h2>
<p><strong>URL</strong>: <a
href="http://netbsd-soc.sourceforge.net/projects/zeroconf/">NetBSD zeroconf
SoC project</a></p>
<p>Add Zeroconf (Rendezvous/Bonjour) support to FreeBSD.</p>
<ul>
<li>Find/write a suitable zeroconf implementation.</li>
<li>Add zeroconf support to the base system daemons.</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>
</ul>
<hr>
<!------------------------------------------------------------------>
<!- Ports ->
<!------------------------------------------------------------------>
<!------------------------------------------------------------------>
<!- Security ->
<!------------------------------------------------------------------>
<!------------------------------------------------------------------>
<!- Userland / Installation Tools ->
<!------------------------------------------------------------------>
<a name="p-noswitches"></a>
<h2>Build options improvements</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:netchild@FreeBSD.org">&a.netchild;</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>
<hr>
<a name="p-impnssldap"></a>
<h2>Import NSS LDAP</h2>
<p>Since LDAP is very popular today, it would be beneficial to have
NSS-LDAP support available by default. The license of the NSS
LDAP module should however be investigated first.</p>
<p><strong>Benefits</strong>:</p>
<ul>
<li>Better user management support in large scale environments out of
the box.</li>
<li>Better user management support in heterogeneous environments out of
the box.</li>
<li>Allows further work for better integration with Active Directory.</li>
<li>Allows further work to enhance the FreeBSD installation process
(guided configuration of the LDAP part).</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
<li>Knowledge of NSS and LDAP.</li>
</ul>
<hr>
<a name="p-hesiodlibc"></a>
<h2>Move HESIOD to a NSS module</h2>
<p>Currently HESIOD is build statically into libc. Since LDAP is more
popular today, it is not necessary to provide this name service to
every consumer of libc by default.</p>
<p><strong>Benefits</strong>:</p>
<ul>
<li>Less code linked to every application.</li>
<li>Less complexity in libc.</li>
<li>More flexibility for system administrators.</li>
<li>More consistent use of subsystems (NSS).</li>
<li>Allows to slim down libc further by moving XDR, RPC and the DNS
code into a separate libraries (may depend upon the NIS/YP -> NSS
entry).</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
</ul>
<hr>
<a name="p-nisyplibc"></a>
<h2>Move NIS/YP to a NSS module</h2>
<p>Currently NIS/YP is build statically into libc. Since LDAP is more
popular today, it is not necessary to provide this name service to
every consumer of libc by default.</p>
<p><strong>Benefits</strong>:</p>
<ul>
<li>Less code linked to every application.</li>
<li>Less complexity in libc.</li>
<li>More flexibility for system administrators.</li>
<li>More consistent use of subsystems (NSS).</li>
<li>Allows to slim down libc further by moving XDR, RPC and the YP
code into a separate libraries (may depend upon the HESIOD -> NSS
entry).</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
</ul>
<hr>
<a name="p-multibyte"></a>
<h2>Multibyte collation support</h2>
<p>Currently FreeBSD supports only single byte collation. Multibyte
collation support would be nice.</p>
<p><strong>Benefits</strong>:</p>
<ul>
<li>Proper national sorting in UTF-8 and other multibyte locales.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
<li>Familiarity with locale subsystem and relevant ISO standards.</li>
</ul>
<hr>
<a name="p-ndmp"></a>
<h2>NDMP data server</h2>
<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>
<hr>
<a name="p-performancetracking"></a>
<h2>Performance tracking</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:brooks@FreeBSD.org">&a.brooks;</a></p>
<p>The "performance tracking" entry is meant to monitor the
performance of FreeBSD itself over the development time, e.g. someone
makes a change to the kernel and the tracking system is able to show
the performance impact to various subsystems (microbenchmarks) or to
real world applications like apache or mysql (macrobenchmarks). The
tracking system should be able to do this with multiple machines and
multiple configurations (while the goal is not to compare
configurations or machines (but different FreeBSD versions) we would
not mind if it is also able to do this. This does not need to be
implemented from scratch, it is allowed/encouraged to reuse existing
free software.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Access to multiple machines.</li>
</ul>
<hr>
<a name="p-libumem"></a>
<h2>Port libumem to FreeBSD</h2>
<p>Solaris 9 and later versions include <code>libumem</code>, a user
space slab allocator that includes debugging features we may want to
have on FreeBSD too.</p>
<p>Online references for <code>libumem</code> are (in suggested reading
order):</p>
<ul>
<li>Robert Benson.
"<em>Identifying Memory Management Bugs Within Applications Using
the libumem Library</em>".
Technical article at
<a href="http://access1.sun.com/">Sun Developer Technical Support</a>.
<a href="http://access1.sun.com/techarticles/libumem.html">http://access1.sun.com/techarticles/libumem.html</a>.
2003.</li>
<li>Jeff Bonwick.
"<em>The Slab Allocator: An Object-Caching Kernel</em>".
USENIX Summer 1994 Technical Conference.
June 6-10, 1994.
<a href="http://www.usenix.org/publications/library/proceedings/bos94/bonwick.html">http://www.usenix.org/publications/library/proceedings/bos94/bonwick.html</a></li>
<li>John Adams and Jeff Bonwick.
"<em>Magazines and Vmem: Extending the Slab Allocator to Many CPUs
and Arbitrary Resources</em>".
<a href="http://www.usenix.org/event/usenix01/index.html">USENIX 2001</a>.
<a href="http://www.usenix.org/event/usenix01/bonwick.html">http://www.usenix.org/event/usenix01/bonwick.html</a></li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C knowledge (reading and writing).</li>
<li>Experience with debugging allocation problems.</li>
</ul>
<hr>
<a name="p-pxeinstaller"></a>
<h2>PXE Installer</h2>
<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><strong>Requirements</strong>:</p>
<ul>
<li>Good PXE knowledge.</li>
</ul>
<hr>
<a name="p-regression"></a>
<h2>Regression testing system</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:nik@FreeBSD.org">&a.nik;</a></p>
<p>&a.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><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of scripting languages (Perl preferred).</li>
<li>Good knowledge of software testing.</li>
</ul>
<hr>
<a name="p-rfc3442"></a>
<h2>RFC3442 support</h2>
<p><strong>Technical contact</strong>: <a
href="mailto:emaste@FreeBSD.org">&a.emaste;</a></p>
<p><strong>URL's</strong>: <a
href="http://www.ietf.org/rfc/rfc3442.txt">RFC3442</a></p>
<p>Add support for RFC3442, the Classless Static Route option, to the DHCP
client. The original DHCP specification includes a route option but it
supports only class-based routes, which are not very useful today.
RFC3442 adds support for specifying the netmask width for each static
route. Note that the ISC dhcp server does not natively support RFC3442, but
custom options of arbitrary byte strings can be encoded in its configuration
file.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Routing knowledge.</li>
</ul>
<hr>
<a name="p-sysinstall"></a>
<h2>Sysinstall</h2>
<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 & keyboard.</li>
<li>Write the FreeBSD version at the top of the display (or somewhere similar
visible) - so lazy users know what they are installing (version: release,
stable, snapshot + arch: i386, amd64, etc) even when the CD is
unlabeled.</li>
<li>Other usability improvements not yet thought of.</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>
<hr>
<a name="p-vi-utf8"></a>
<h2>Unicode support in vi</h2>
<p>Many base system utilities grew multibyte support in 2004. It would be
nice to continue this trend by teaching &man.vi.1; to display and edit
documents in UTF-8 encoding.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
</ul>
<hr>
<!------------------------------------------------------------------>
<!- Additional Information ->
<!------------------------------------------------------------------>
<a name="p-projects"></a>
<h2>Projects at FreeBSD.org</h2>
<p>Additional projects may be found by browsing the <a
href="../projects.html">FreeBSD Development Projects page</a>. The most
prominent projects are:</p>
<ul>
<li><a href="../acpi/index.html">The FreeBSD ACPI Project</a></li>
<li><a href="../c99/index.html">C99 & POSIX Conformance Project</a></li>
<li><a href="../bigdisk/index.html">Large data storage in FreeBSD
Project</a></li>
<li><a href="../netperf/index.html">Network Performance Project</a></li>
<li><a href="../dingo/index.html">Network Cleanup and Consolidation
Project</a></li>
<li><a href="../busdma/index.html">busdma and SMPng driver conversion
Project</a></li>
</ul>
<p>Do not forget to have a look at the other projects too or by viewing some
of the recent <a href="&base;/news/status">Developer Status Reports.</a></p>
<hr>
<a name="p-tc"></a>
<h2>Technical contacts</h2>
<p>If you are interested in working on a project not explicitly
mentioned above, you may want to contact one of the potential
technical contacts below:</p>
<ul>
<li><strong>ACPI</strong>:
<a href="mailto:njl@FreeBSD.org">&a.njl;</a>
<a href="mailto:bruno@FreeBSD.og">&a.bruno;</a>.</li>
<li><strong>File systems</strong>:
<a href="mailto:scottl@FreeBSD.org">&a.scottl;</a>,
<a href="mailto:alfred@FreeBSD.org">&a.alfred;</a>.</li>
<li><strong>GEOM</strong>:
<a href="mailto:pjd@FreeBSD.org">&a.pjd;</a>,
<a href="mailto:phk@FreeBSD.org">&a.phk;</a>.</li>
<li><strong>Networking</strong>:
<a href="mailto:alfred@FreeBSD.org">&a.alfred;</a>,
<a href="mailto:brooks@FreeBSD.org">&a.brooks;</a>,
<a href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a>,
<a href="mailto:sam@FreeBSD.org">&a.sam;</a>.</li>
<li><strong>Release Engineering / Integration</strong>:
<a href="mailto:re@FreeBSD.org">Release Engineering Team</a>.</li>
<li><strong>Sound</strong>:
<a href="mailto:ariff@FreeBSD.org">&a.ariff;</a>.</li>
<li><strong>TrustedBSD / Security</strong>:
<a href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a>.</li>
</ul>
<p>Additionally, there are a lot of interesting <a
href="&base;/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">mailing
lists</a> that can be used when searching information about specific
subjects.</p>
<hr>
&footer;
</body>
</html>
Reference in a new issue View git blame Copy permalink