1276 lines
50 KiB
Text
1276 lines
50 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
|
<!ENTITY base CDATA "../..">
|
|
<!ENTITY date "$FreeBSD: www/en/projects/ideas/index.sgml,v 1.22 2006/02/12 08:17:21 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;
|
|
]>
|
|
|
|
<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> or <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>
|
|
|
|
<h2>Project ideas</h2>
|
|
|
|
<h3>File System</h3>
|
|
<ul>
|
|
<li><a href="#p-tmpfs">Port the NetBSD tmpfs (efficient memory
|
|
file system)</a></li>
|
|
<li><a href="#p-autofs">Autofs</a></li>
|
|
<li><a href="#p-magicsymlinks">Implement Magic Symlinks</a></li>
|
|
<li><a href="#p-mdfs">Fix mdfs lockups when using non-sync operation
|
|
modes</a></li>
|
|
</ul>
|
|
|
|
<h3>Kernel</h3>
|
|
<ul>
|
|
<li><a href="#p-kbdmux">Working kbdmux</a></li>
|
|
<li><a href="#p-psched">Port the "Pluggable Disk Schedulers" SoC project to
|
|
current/GEOM</a></li>
|
|
<li><a href="#p-usbnetbsd">Sync USB code with NetBSD</a></li>
|
|
<li><a href="#p-sxsemantics">Usable lock implementation with
|
|
SX-semantics</a></li>
|
|
<li><a href="#p-docsysctl">Document as many sysctls as possible</a></li>
|
|
<li><a href="#p-docsound">Document the sound subsystem</a></li>
|
|
<li><a href="#p-sync4front">Syncing with the 4Front Technologies OSS v4
|
|
API</a></li>
|
|
<li><a href="#p-implement4front">Implement necessary kernel interface for
|
|
4Front Technologies ALSA to OSS wrapper (SALSA)</a></li>
|
|
<li><a href="#p-soundlocking">Improve locking of the sound
|
|
system</a></li>
|
|
<li><a href="#p-hda">Add High Definition Audio (HDA) support to our sound
|
|
system</a></li>
|
|
<li><a href="#p-geninput">Implement a generic input device layer</a></li>
|
|
<li><a href="#p-camlocking">Add locking to the CAM layer</a></li>
|
|
<li><a href="#p-iscsi">Implement iSCSI</a></li>
|
|
<li><a href="#p-processcheck">Port DragonFly's process
|
|
checkpointing</a></li>
|
|
<li><a href="#p-memcpy">Evaluate and perhaps port DragonFly's MMX/XMM optimized
|
|
memcpy/bcopy/bzero/copyin/copyout code (this includes an FPU subsystem
|
|
overhaul)</a></li>
|
|
<li><a href="#p-bootcode">Evaluate and perhaps sync FreeBSD i386 boot code
|
|
with DragonFly's boot code</a></li>
|
|
<li><a href="#p-cpuusage">Fix the CPU usage display in top for threaded
|
|
processes</a></li>
|
|
<li><a href="#p-pcihotplug">Implement PCI-Hotplug support</a></li>
|
|
<li><a href="#p-dtrace">Implement something similar to Solaris'
|
|
DTrace</a></li>
|
|
<li><a href="#p-amd64linux">Add amd64 native support to the
|
|
Linuxulator</a></li>
|
|
<li><a href="#p-updatelinux">Update the Linuxulator</a></li>
|
|
<li><a href="#p-assembler">Annotate every assembler file [*.[sS]] with
|
|
dwarf2 call frame information</a></li>
|
|
<li><a href="#p-suspend">Suspend to disk</a></li>
|
|
<li><a href="#p-algopowerd">Implement and profile various algorithms for
|
|
powerd</a></li>
|
|
<li><a href="#p-modrefcnt">Dynamic module references</a></li>
|
|
<li><a href="#p-ktrace">Add some more information in the
|
|
ktrace(1)/kdump(1) output.</a></li>
|
|
<li><a href="#p-hesiodlibc">Move HESIOD out of libc into a NSS
|
|
module</a></li>
|
|
<li><a href="#p-nisyplibc">Move NIS/YP out of libc into a NSS
|
|
module</a></li>
|
|
<li><a href="#p-impnssldap">Import NSS LDAP support into the base
|
|
system.</a></li>
|
|
<li><a href="#p-rewritesyncer">Rewrite the in-kernel file system syncer and
|
|
modernize the write behind code</a></li>
|
|
</ul>
|
|
|
|
<h3>Networking</h3>
|
|
<ul>
|
|
<li><a href="#p-csup">Contribute to the csup project</a></li>
|
|
<li><a href="#p-zeroconf">Add zeroconf (Rendezvous/Bonjour) support to
|
|
FreeBSD</a></li>
|
|
<li><a href="#p-networkdisk">Network Disk Device</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-web100">Port Web100 to FreeBSD</a></li>
|
|
<li><a href="#p-wpa2preauth">WPA2 preauthentication support in
|
|
hostapd</a></li>
|
|
<li><a href="#p-iapp">IAPP preauthentication support in hostapd</a></li>
|
|
<li><a href="#p-wi">Bring wi(4) up to par with the current state of affairs
|
|
in the WLAN infrastructure</a></li>
|
|
<li><a href="#p-appletalk">Re-factor Apple Talk into a kernel module</a></li>
|
|
</ul>
|
|
|
|
<h3>Security</h3>
|
|
<ul>
|
|
<li><a href="#p-securemines">SecureMines</a></li>
|
|
</ul>
|
|
|
|
<h3>Userland / Installation Tools</h3>
|
|
<ul>
|
|
<li><a href="#p-smpinstall">SMP kernels for install</a></li>
|
|
<li><a href="#p-sysinstall">Small sysinstall renovation</a></li>
|
|
<li><a href="#p-sysinstall2">Extract the partition and slice table editor
|
|
from sysinstall</a></li>
|
|
<li><a href="#p-pxeinstaller">Bundled PXE Installer</a></li>
|
|
<li><a href="#p-regression">Improve our regression testing system</a></li>
|
|
<li><a href="#p-performancetracking">Tracking performance over time</a></li>
|
|
<li><a href="#p-ndmp">Write a NDMP data server</a></li>
|
|
<li><a href="#p-noswitches">Add support for NO_* switches to
|
|
"make delete-old"</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>
|
|
|
|
<a name="p-tmpfs"></a>
|
|
<h2>Port the NetBSD tmpfs (efficient memory file system)</h2>
|
|
<p>At the moment FreeBSD includes a memory-based file system called mfs.
|
|
mfs is 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><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-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. Most of this work is
|
|
done, however, 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>Implement 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>Fix mdfs lockups when using non-sync operation modes</h2>
|
|
<p><a href="&cgibase;/cvsweb.cgi/sys/dev/md/md.c#rev1.115">Rev. 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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-kbdmux"></a>
|
|
<h2>Working kbdmux</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:emax@FreeBSD.org">&a.emax;</a></p>
|
|
<p>We need this for the growing number of systems that
|
|
assume that USB is the primary keyboard. Current status appears to be
|
|
that the kbdmux driver breaks very easily. We need this working well
|
|
enough where it can be enabled by default, and all attached keyboards
|
|
Just Work. This needs to be resolved as soon as possible.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>C knowledge.</li>
|
|
<li>Understanding of FreeBSD keyboard/console drivers.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-psched"></a>
|
|
<h2>Port the "Pluggable Disk Schedulers" SoC project to current/GEOM</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:s223560@studenti.ing.unipi.it">Emiliano Mennucci</a></p>
|
|
<p><strong>URL</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 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-usbnetbsd"></a>
|
|
<h2>Sync USB code with NetBSD</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:usb@FreeBSD.org">usb@FreeBSD.org</a> (mailing list)</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-sxsemantics"></a>
|
|
<h2>Usable lock implementation with SX-semantics</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:mlaier@FreeBSD.org">&a.mlaier;</a></p>
|
|
<p><strong>URL</strong>: <a
|
|
href="http://wikitest.freebsd.org/moin.cgi/Usable_20lock_20implementation_20with_20SX_2dsemantics">Project
|
|
page on the wiki</a></p>
|
|
<p>The current sx(9) implementation has several problems that make it unusable
|
|
in many areas: Might sleep (cv_wait) on the shared lock acquisition,
|
|
implicit, hardcoded priority order without starvation protection, ... There
|
|
are several handrolled lock implementations with SX-semantics in the tree
|
|
already that solve some of the problems in their specific domain: MAC, pfil,
|
|
ipfw, if_bridge, ...</p>
|
|
<ul>
|
|
<li>Review existing uses of non-standard sx-locks.</li>
|
|
<li>Design an API usable to replace most/all of the handrolled hacks or find
|
|
an existing API to do the same.</li>
|
|
<li>Write the actual code.</li>
|
|
</ul>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>C knowledge.</li>
|
|
<li>Knowledge about shared/exclusive locking in SMP systems.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-docsysctl"></a>
|
|
<h2>Document as many sysctls as possible</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><!-- Glenn Dawson <glenn@antimatter.net> -->
|
|
|
|
<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>
|
|
<p><!-- Description needed --></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-sync4front"></a>
|
|
<h2>Syncing with the 4Front Technologies OSS v4 API</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
|
|
<p><strong>URL</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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-implement4front"></a>
|
|
<h2>Implement necessary kernel interface for 4Front Technologies ALSA to OSS
|
|
wrapper (SALSA)</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
|
|
<p><strong>URL</strong>: <a href="http://www.opensound.com/">4Front
|
|
Technologies</a>, <a
|
|
href="http://www.4front-tech.com/forum/viewtopic.php?t=296">SALSA</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>At least one supported sound card.</li>
|
|
</ul><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-soundlocking"></a>
|
|
<h2>Improve locking of the sound system</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:ariff@FreeBSD.org">&a.ariff;</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 the FreeBSD locking methods.</li>
|
|
</ul><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-hda"></a>
|
|
<h2>Add High Definition Audio (HDA) support to our sound system</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:ariff@FreeBSD.org">&a.ariff;</a></p>
|
|
<p><!-- Description needed --></p>
|
|
<p><strong>URL</strong>: <a href="http://www.intel.com/standards/hdaudio/">HDA
|
|
Specification</a></p>
|
|
<p><strong>NetBSD azalia driver</strong>: <a
|
|
href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/azalia.c">azalia.c</a>,
|
|
<a
|
|
href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/azalia.h">azalia.h</a>,
|
|
<a
|
|
href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/azalia_codec.c">azalia_codec.c</a></p>
|
|
<ul>
|
|
<li>Have a look at the specification.</li>
|
|
<li>Implement HDA 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>HDA sound card.</li>
|
|
</ul><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-geninput"></a>
|
|
<h2>Implement a 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><!-- netchild, philip -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-camlocking"></a>
|
|
<h2>Add locking to the CAM layer</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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-iscsi"></a>
|
|
<h2>Implement 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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-processcheck"></a>
|
|
<h2>Port DragonFly's 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 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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-memcpy"></a>
|
|
<h2>Evaluate and perhaps port DragonFly's optimized MMX/XMM memcpy/bcopy/bzero/copyin/copyout
|
|
code (this includes an FPU subsystem overhaul)</h2>
|
|
<p>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><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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-bootcode"></a>
|
|
<h2>Evaluate and perhaps sync FreeBSD i386 boot code with DragonFly's boot
|
|
code</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 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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-cpuusage"></a>
|
|
<h2>Fix the CPU usage display in top for threaded processes</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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-pcihotplug"></a>
|
|
<h2>Implement 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 the FreeBSD device drivers.</li>
|
|
</ul><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-dtrace"></a>
|
|
<h2>Implement something similar to Solaris' DTrace</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:dodell@iXsystems.com">Devon H. O'Dell</a></p>
|
|
<p><strong>URL</strong>: <a href="http://www.sitetronics.com:8080/">Perforce
|
|
repository</a></p>
|
|
<p>Need to get the DTrace provider working. This is the epicenter of DTrace
|
|
and it is the first step to making the rest of it work from the kernel side
|
|
of things. Userland stuff is 98% done. The other 2% will be addressed later
|
|
when some kernel dependencies are satisfied.</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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-amd64linux"></a>
|
|
<h2>Add amd64 native support to the Linuxulator</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><!-- netchild -->
|
|
|
|
<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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-assembler"></a>
|
|
<h2>Annotate every assembler file [*.[sS]] with 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.</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><!-- netchild: peter via arch -->
|
|
|
|
<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-algopowerd"></a>
|
|
<h2>Implement and profile various 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-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>Add some more information in the ktrace(1)/kdump(1) 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.</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-hesiodlibc"></a>
|
|
<h2>Move HESIOD out of libc into 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 out of libc into 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-impnssldap"></a>
|
|
<h2>Import NSS LDAP support into the base system</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-rewritesyncer"></a>
|
|
<h2>Rewrite the in-kernel file system syncer and modernize the write behind
|
|
code</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-csup"></a>
|
|
<h2>Contribute to the csup project</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. A rewrite in
|
|
C would allow the FreeBSD project to include the functionality of CVSup into
|
|
the FreeBSD base system, instead of shipping it as a separate package.
|
|
You can find snapshots of csup,
|
|
along with a CVSWeb interface to the code and much more by following the
|
|
links above. It is also available from the Ports Collection, which should
|
|
make it somewhat easier for curious people to test.</p>
|
|
<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-zeroconf"></a>
|
|
<h2>Add zeroconf (Rendezvous/Bonjour) support to FreeBSD</h2>
|
|
<p><strong>URL</strong>: <a
|
|
href="http://netbsd-soc.sourceforge.net/projects/zeroconf/">NetBSD zeroconf
|
|
SoC project</a></p>
|
|
<p><!-- Description needed --></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><!-- netchild -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-networkdisk"></a>
|
|
<h2>Network Disk Device</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
|
<p>Add the ability to remotely access devices from one system to another. The
|
|
goal is to allow remote access to resources such as disks, sound devices,
|
|
and other miscellaneous pieces of hardware over the network. This project
|
|
would be a good resume builder, but is not for the faint of heart.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Understanding or interest in remote procedure call systems.</li>
|
|
<li>Understanding or interest in networking (TCP/IP).</li>
|
|
<li>Interest to learn how &unix; device drivers work as well as process
|
|
management.</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>
|
|
<p><!-- Description needed --></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-web100"></a>
|
|
<h2>Port Web100 to FreeBSD</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:brooks@FreeBSD.org">&a.brooks;</a></p>
|
|
<p><strong>URL</strong>: <a
|
|
href="http://www.web100.org/">The Web100 project</a></p>
|
|
<p>The Web100 project was created to address the problems of TCP performance
|
|
over long-fat network pipes. They created an interesting set of tuning and
|
|
monitoring patches for Linux which enable significantly better performance
|
|
in this area. Integrating this work into FreeBSD could provide significant
|
|
benefits in terms of TCP performance in certain environments.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of C.</li>
|
|
<li>The features of Web100 need to be mapped into appropriate FreeBSD
|
|
abstractions and integrated into the system.</li>
|
|
<li>The performance impact of these changes would have to be quantified
|
|
before the changes could be introduced.</li>
|
|
<li>Good understanding of the TCP protocol.</li>
|
|
<li>Good understanding of kernel interfaces.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-wpa2preauth"></a>
|
|
<h2>WPA2 preauthentication support 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-iapp"></a>
|
|
<h2>IAPP preauthentication support 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-wi"></a>
|
|
<h2>Bring wi(4) up to par with the current state of affairs in the WLAN
|
|
infrastructure</h2>
|
|
<p>Many new and useful features (e.g. crypto protocols like WPA) of the WLAN
|
|
infrastructure in the kernel are not used in wi(4). While 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 wi(4) driver.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C.</li>
|
|
<li>No fear to "use the source Luke" and to have a look at undocumented
|
|
parts of the kernel.</li>
|
|
<li>At least one wi(4) card and one other wireless device to test
|
|
against.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-appletalk"></a>
|
|
<h2>Re-factor Apple Talk into a kernel module</h2>
|
|
<p>At the moment the Apple Talk protocol is only available as a compile time
|
|
option. The goal of this item is to allow to load the Apple Talk protocol
|
|
at runtime (as part of netgraph or as a "standalone" module) and to add
|
|
appropriate locking (as a start even a generic subsystem lock would be ok,
|
|
more fine grained locking can be added later).</p>
|
|
<p><strong>Benefits</strong>:</p>
|
|
<ul>
|
|
<li>No need to rebuild the kernel.</li>
|
|
<li>No speed decrease of other network protocols when Apple Talk is used
|
|
(because of degrading the entire network stack into non-MPSAFE mode).</li>
|
|
</ul>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C.</li>
|
|
<li>Knowledge of Apple Talk.</li>
|
|
<li>Knowledge of the network stack.</li>
|
|
<li>Maybe knowledge of netgraph.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-securemines"></a>
|
|
<h2>SecureMines</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
|
<p>Add meta-data to the system in order to trap intruders and provide an audit
|
|
log. The goal of this project is to create several means of marking an event
|
|
as a foreign act (such as opening a trap file) which halts the system and
|
|
provides as much information as possible, possibilities include using
|
|
extended attributes to tag such "mines".</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of C.</li>
|
|
<li>Good understanding of the Unix process model.</li>
|
|
<li>Good understanding of the FreeBSD kernel.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-smpinstall"></a>
|
|
<h2>SMP kernels for install</h2>
|
|
<p>Right now we only install a UP kernel, for
|
|
performance reasons. We should be able to package both a UP and SMP
|
|
kernel into the release bits, and have sysinstall install both. It
|
|
should also select the correct one for the target system and make that
|
|
the default on boot. The easiest way to do this would be to have
|
|
sysinstall boot an SMP kernel and then look at the hw.ncpu sysctl. The
|
|
only problem is being able to have sysinstall fall back to booting a UP
|
|
kernel for itself if the SMP one fails. This can probably be 'faked' by
|
|
setting one of the SMP-disabling variables in the loader. But in any
|
|
case, the point is to make the process Just Work for the user, without
|
|
the user needing to know arcane loader/sysctl knobs. SMP laptops are
|
|
here, and we should be ready to support SMP out-of-the-box. This needs
|
|
to be resolved as soon as possible.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of C.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-sysinstall"></a>
|
|
<h2>Small sysinstall renovation</h2>
|
|
<p><!-- Description needed --></p>
|
|
<ul>
|
|
<li>Ask for country & keyboard layout at start - so international keyboards
|
|
work correctly.</li>
|
|
<li>Ask for network configuration before install - so you do not have to
|
|
configure the net twice.</li>
|
|
<li>Get hostname from dhcp server as well.</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><!-- Martin Nilsson <martin@mullet.se> -->
|
|
|
|
<hr>
|
|
|
|
<a name="p-sysinstall2"></a>
|
|
<h2>Extract the partition and slice table editor from sysinstall</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
|
|
<p>The partition and slice table editor in sysinstall is not only useful at
|
|
system installation time, it is also a nice tool to handle new disks in an
|
|
already setup system. The goal of this entry is to extract (and perhaps
|
|
enhance) this editor from sysinstall into a standalone tool. This allows us
|
|
to remove sysinstall when the new installer enters the tree without loosing
|
|
nice functionality. Additionally novice users cannot shoot themselves in the
|
|
foot by accidentally triggering the wrong actions in unrelated parts of
|
|
sysinstall.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-pxeinstaller"></a>
|
|
<h2>Bundled 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>Improve our 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-performancetracking"></a>
|
|
<h2>Tracking performance over time</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:brooks@FreeBSD.org">&a.brooks;</a></p>
|
|
<p>One of the major issues in a project with the size of FreeBSD is monitoring
|
|
changes in performance characteristics over time. Doing this requires
|
|
several things. Those include a suite of appropriate tests, hardware to
|
|
run the tests on, a database to store results in, and software to
|
|
extract interesting results and display them. Solving the whole problems
|
|
is probably beyond the scope of one summer's work, but an interesting
|
|
subset should be manageable.</p>
|
|
|
|
<hr>
|
|
|
|
<a name="p-ndmp"></a>
|
|
<h2>Write a 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-noswitches"></a>
|
|
<h2>Add support for NO_* switches to "make delete-old"</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 NO_* knobs, e.g. NO_RESCUE or
|
|
NO_CRYPT, and delete files which are covered by those knobs.</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-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: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>
|