1445 lines
59 KiB
Text
1445 lines
59 KiB
Text
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
|
|
<!ENTITY base CDATA "../..">
|
|
<!ENTITY date "$FreeBSD: www/en/projects/ideas/index.sgml,v 1.93 2007/02/26 17:32:53 joel Exp $">
|
|
<!ENTITY title "FreeBSD list of projects and ideas for volunteers">
|
|
<!ENTITY % navinclude.developers "INCLUDE">
|
|
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
|
|
<!ENTITY man.vi.1 "<a href='http://www.FreeBSD.org/cgi/man.cgi?query=vi&sektion=1'>vi(1)</a>">
|
|
<!ENTITY man.wi.4 "<a href='http://www.FreeBSD.org/cgi/man.cgi?query=wi&sektion=4'>wi(4)</a>">
|
|
<!ENTITY man.tar.1 "<a href='http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=1'>tar(1)</a>">
|
|
]>
|
|
|
|
<!--
|
|
README
|
|
|
|
1. Feel free to commit new ideas to the list, but try to follow the existing
|
|
style used in this document.
|
|
2. Big structural changes should be done in collaboration with joel. He is
|
|
always working on improvements and would like to review major changes
|
|
before they are committed to the tree.
|
|
3. Keep entries sorted alphabetically.
|
|
-->
|
|
|
|
<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-msdosfs">FAT (msdosfs) infrastructure work</a></li>
|
|
<li><a href="#p-extenddump">Improve the performance of dump/restore</a></li>
|
|
<li><a href="#p-mdfs">MDFS lockups</a></li>
|
|
<li><a href="#p-tmpfs">TMPFS</a></li>
|
|
</ul>
|
|
|
|
<h3>Kernel</h3>
|
|
<ul>
|
|
<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-fastcall">Fast syscall support for FreeBSD/i386</a></li>
|
|
<li><a href="#p-geninput">Generic input device layer</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-busalloc">New bus_alloc_resources() API.</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-sensors">Port OpenBSD's sensors framework</a></li>
|
|
<li><a href="#p-trussprocfs">Remove procfs dependencies</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-sysmod">Syscons modularization</a></li>
|
|
</ul>
|
|
|
|
<h3>Networking</h3>
|
|
<ul>
|
|
<li><a href="#p-csup">csup improvements</a></li>
|
|
<li><a href="#p-httppxe">HTTP support for pxeboot</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-pfnetgraph">pf and netgraph interaction</a></li>
|
|
<li><a href="#p-suptundaemon">Super tunnel daemon</a></li>
|
|
<li><a href="#p-tcpipreg">TCP/IP regression test suite</a></li>
|
|
<li><a href="#p-wi">Update wi</a></li>
|
|
<li><a href="#p-wpa2preauth">WPA2 preauthentication in hostapd</a></li>
|
|
</ul>
|
|
|
|
<h3>Ports</h3>
|
|
<ul>
|
|
<li><a href="#p-ports-db">Add hashed .db support to pkg_tools</a></li>
|
|
<li><a href="#p-ports-uid">Automatic registering of UID and GID</a></li>
|
|
<li><a href="#p-ports-cleanup-use">Cleanup of USE and WITH variables</a></li>
|
|
<li><a href="#p-ports-comp43tty">COMPAT_43TTY</a></li>
|
|
<li><a href="#p-ports-options">Improvements of OPTIONS</a></li>
|
|
<li><a href="#p-ports-pkgtools">Package tools improvements</a></li>
|
|
</ul>
|
|
|
|
<h3>Security</h3>
|
|
<ul>
|
|
<li><a href="#p-auditkernel">Audit kernel event sources</a></li>
|
|
<li><a href="#p-distribaudit">Distributed audit daemon</a></li>
|
|
<li><a href="#p-mac">Mandatory Access Control</a></li>
|
|
<li><a href="#p-securityregression">Security regression tests</a></li>
|
|
</ul>
|
|
|
|
<h3>Userland / Installation Tools</h3>
|
|
<ul>
|
|
<li><a href="#p-bsdelftools">BSD-licensed ELF Tools</a></li>
|
|
<li><a href="#p-noswitches">Build options improvements</a></li>
|
|
<li><a href="#p-lint">lint(1) improvements from OpenBSD</a></li>
|
|
<li><a href="#p-libprocnet">Libprocstat and libnetstat</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-prebind">Port prebind from OpenBSD</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-sysinstall">Sysinstall</a></li>
|
|
<li><a href="#p-taroutmode">Tar output mode for installworld</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-msdosfs"></a>
|
|
<h2>FAT (msdosfs) infrastructure work</h2>
|
|
<p><strong>Technical Contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>The FreeBSD FAT implementation, msdosfs, offers scope for a number of
|
|
projects:</p>
|
|
<ul>
|
|
<li>General cleanup.</li>
|
|
<li>Introduce appropriate locking to make the file system operate without
|
|
the Giant lock (MPSAFE).</li>
|
|
<li>Make msdosfs robust in the presence of unexpected disk removal, since
|
|
it is frequently used with removable devices.</li>
|
|
</ul>
|
|
<p>It is unclear to what extent the last of these items, arguably the most
|
|
useful, will require modifying surrounding infrastructure such as BIO,
|
|
GEOM, and VM.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong C programming skills.</li>
|
|
<li>Familiarity with concurrent programming techniques.</li>
|
|
<li>Familiarity with FAT file system layout.</li>
|
|
<li>Familiarity with virtual file system and virtual memory.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-extenddump"></a>
|
|
<h2>Improve the performance of dump/restore</h2>
|
|
<p>A performance evaluation of the split cache (as is) and an unified cache
|
|
(like e.g. NetBSD) would be interesting. More details in <a
|
|
href="http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html">
|
|
this</a> mail to the hackers mailing list. Additional improvements are
|
|
welcome too.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C programming.</li>
|
|
<li>Basic understanding of backup/restore procedures.</li>
|
|
</ul>
|
|
|
|
<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><strong>Technical contact</strong>: <a
|
|
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
|
|
<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. The source and some benchmarks can be found
|
|
<a href="http://download.purpe.com/tmpfs">here</a>. Before it can enter the
|
|
tree locking has to be added. There are also <a
|
|
href="http://www.Leidinger.net/FreeBSD/tmpfs_bugs.mails">some bugs</a> to take
|
|
care of. Rohit has no time to work on it in the next months, any volunteer is
|
|
welcome to continue his work.</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>
|
|
|
|
<!------------------------------------------------------------------>
|
|
<!- Kernel ->
|
|
<!------------------------------------------------------------------>
|
|
|
|
<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. This problem only
|
|
occurs with M:N threading on libpthread.</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>
|
|
<li>A <a href="http://wiki.freebsd.org/soundsystem">wiki page</a>
|
|
documenting everything related to the sound subsystem in FreeBSD has been
|
|
created.</li>
|
|
</ul>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Ability to read and understand foreign C code.</li>
|
|
<li>Documentation writing skills.</li>
|
|
</ul>
|
|
|
|
<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. &a.jb; has created an initial port and
|
|
should be contacted for information on what tasks remain to be done.</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>Also, a related project would be to modify ktrace to write to pipes.
|
|
Currently the ktrace infrastructure requires the dump output go to a file.
|
|
It would be useful to be able to instead have it write to pipe, or in fact
|
|
any type of file descriptor.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C.</li>
|
|
<li>Good knowledge of POSIX interfaces or how to use man(1).</li>
|
|
<li>No fear to look into the kernel sources.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-fastcall"></a>
|
|
<h2>Fast syscall support for FreeBSD/i386</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rookie@gufi.org">Attilio Rao</a></p>
|
|
<p>The instruction pair sysenter and sysexit can contribute to certain
|
|
performance improvements when a syscall is made on IA32. There is however
|
|
no implementation of this available for FreeBSD, so a volunteer
|
|
would have to add sysenter/sysexit support to the kernel. This
|
|
needs to be properly evaluated and benchmarked though, so a complete
|
|
implementation should therefore also contain informative benchmarks which
|
|
shows a clear improvement in performance. It is also important to stress
|
|
the fact that this project is of research quality and measures should be
|
|
taken to ensure that no regressions are introduced. Another interesting
|
|
extension to this project would be to investigate and evaluate the
|
|
possibility to use mmx/xmm registers to gather syscalls arguments.
|
|
<a href="mailto:davidxu@FreeBSD.org">&a.davidxu;</a> has some <a
|
|
href="http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064403.html">work
|
|
in progress</a> in his <a
|
|
href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/davidxu/sysenter">sysenter</a>
|
|
branch in the perforce repository.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Ability to read and understand foreign C code.</li>
|
|
<li>Ability to write C code.</li>
|
|
<li>Ability to write and understand x86 assembly.</li>
|
|
</ul>
|
|
|
|
<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-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-busalloc"></a>
|
|
<h2>New bus_alloc_resources() API</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:imp@FreeBSD.org">&a.imp;</a></p>
|
|
<p>Recently, bus_alloc_resources has been added to the kernel. This,
|
|
coupled with the bus_space_{read,write} family of functions can
|
|
significantly reduce the setup needed for driver resource allocation.
|
|
Unfortunately, most of the drivers in the tree have not yet been
|
|
converted, thus ensuring that the old, bad way continues. What is needed
|
|
is for someone to go through the drivers in the tree and convert them.
|
|
After conversion, they need to ensure that they still work on at least some
|
|
hardware and work with someone to get them committed. <a
|
|
href="mailto:imp@FreeBSD.org">&a.imp;</a> is available for review and
|
|
coordination of committing.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Ability to read, write and understand C code.</li>
|
|
<li>Knowledge about device drivers.</li>
|
|
<li>Access to hardware to test on.</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://wiki.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-sensors"></a>
|
|
<h2>Port OpenBSD's sensors framework</h2>
|
|
<p><strong>References</strong>: <a
|
|
href="http://www.openbsd.org/papers/bsdcan06-biosensors.pdf">Overview</a>,
|
|
<a href="http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/">
|
|
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/</a>,
|
|
<a href="http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/bioctl/">
|
|
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/bioctl/</a>, <a
|
|
href="http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/safte.c">
|
|
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/safte.c</a></p>
|
|
<p>The OpenBSD sensors framework is an unified way of handling
|
|
any kind of hardware sensor one can image. A sensor driver collects
|
|
data from system sensors, SAS devices, harddisks, ... and allows an
|
|
administrator to query the data with the unified management interface.</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 dependencies</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).
|
|
Removing the procfs(5) dependency from ps -e is also desirable.</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-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. Introduce fine-grained locking. 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>
|
|
|
|
<!------------------------------------------------------------------>
|
|
<!- 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-httppxe"></a>
|
|
<h2>HTTP support for pxeboot</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>Implementing HTTP support for pxeboot would allow us to boot a machine using
|
|
PXE and pull down a kernel from a web server rather than NFS. This will
|
|
allow us to install from DHCPD + Apache or even just DHCPD + a remote web
|
|
server. As PXE does not provide an integrated TCP stack, at least a
|
|
minimal TCP implementation would need to be present in the FreeBSD PXE
|
|
loader.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good PXE knowledge.</li>
|
|
<li>Detailed knowledge of TCP/IP.</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-pfnetgraph"></a>
|
|
<h2>pf and netgraph interaction</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:mlaier@FreeBSD.org">&a.mlaier;</a></p>
|
|
<p>Teach pf to talk to the netgraph subsystem. Requires a design on how to
|
|
express this in pf.conf and implementation. Being able to use divert
|
|
sockets would be interesting as well and should be largely parallel with
|
|
regards to the design.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of C.</li>
|
|
<li>Good understanding of kernel level networking.</li>
|
|
<li>Basic understanding of pf and netgraph as a user at least.</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-tcpipreg"></a>
|
|
<h2>TCP/IP regression test suite</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a>, <a
|
|
href="mailto:gnn@FreeBSD.org">&a.gnn;</a></p>
|
|
<p>Design and implement a wire level regression test suite to exercise various
|
|
states in the TCP/IP protocol suite. Ideally with both IPv4 and IPv6
|
|
support.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong TCP/IP knowledge.</li>
|
|
</ul>
|
|
|
|
<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>
|
|
|
|
<!------------------------------------------------------------------>
|
|
<!- Ports ->
|
|
<!------------------------------------------------------------------>
|
|
|
|
<a name="p-ports-db"></a>
|
|
<h2>Add hashed .db support to pkg_tools</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:kris@FreeBSD.org">&a.kris;</a></p>
|
|
<p>pkg_create(1) and friends use flat databases (aka ordinary
|
|
files and directories in /var/db/pkg) to maintain their data. This
|
|
makes it cumbersome and/or impossible to do efficient lookups of data
|
|
on installed packages and makes certain operations very slow.
|
|
portupgrade has the right idea of hashing this into a berkeley db
|
|
file, but it uses tools that are not in the base system (ruby).</p>
|
|
<p>A self-contained project would be to add similar (preferably
|
|
compatible) code into pkg_tools directly, possibly also extending
|
|
the data that is stored and allowing for more flexible querying with
|
|
tools like pkg_info (e.g. replicating the pkg_which utility of
|
|
portupgrade). Adding mutual exclusion to protect concurrent
|
|
pkg_add/delete operations from corrupting database state is also
|
|
important.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C.</li>
|
|
<li>Basic understanding of the use of berkeley db.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-ports-uid"></a>
|
|
<h2>Automatic registering of UID and GID</h2>
|
|
<p>Some sort of mechanism for adding/removing users/groups automatically,
|
|
rather than using home-brew pkg-install scripts. It would need to be
|
|
a bit more sophisticated than only registering the UID/GID, to deal with
|
|
setting the other passwd(5) fields; a port might need more than
|
|
one user; some ports might want a specific ID, others just the next
|
|
available one, etc, etc.</p>
|
|
<p>Perhaps ports that have UIDs registered in the handbook could also
|
|
be registered in a file inside /usr/ports, which the framework would
|
|
use in UID creation requests.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong knowledge of shell and make code.</li>
|
|
<li>A basic understanding of the inner workings of the ports tree.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-ports-cleanup-use"></a>
|
|
<h2>Cleanup of USE and WITH variables</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:erwin@FreeBSD.org">&a.erwin;</a></p>
|
|
<p>Make these more consistent. WITH_* should be user-settable
|
|
variables while USE_* only is for internal use in the ports.</p>
|
|
<p><strong>Requirement</strong>:</p>
|
|
<ul>
|
|
<li>Strong knowledge of shell and make code.</li>
|
|
<li>A basic understanding of the inner workings of the ports tree.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-ports-comp43tty"></a>
|
|
<h2>COMPAT_43TTY</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:gbell72@rogers.com">Gardner Bell</a></p>
|
|
<p>Some ports may break when removing COMPAT_43TTY from the kernel
|
|
configuration since they assume old ioctl's when they identify
|
|
FreeBSD. The goal of this entry is to:</p>
|
|
<ul>
|
|
<li>Identify the ports which behave like this. A tinderbox setup is probably
|
|
needed. Using grep to find "#include <sgtty.h>" and this <a
|
|
href="http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064010.html">list</a>
|
|
from &a.kris; might also be good starting points.</li>
|
|
<li>Fix breakages and send patches upstream.</li>
|
|
</ul>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of autotools.</li>
|
|
<li>Time and patience.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-ports-options"></a>
|
|
<h2>Improvements of OPTIONS</h2>
|
|
<p>The current OPTIONS infrastructure can be improved in several ways.</p>
|
|
<ul>
|
|
<li>It should be possible to define OPTIONS after bsd.ports.pre.mk.</li>
|
|
<li>Add an API to override the current curses based interface with
|
|
a different GUI, e.g. zenity/gdialog instead of dialog.</li>
|
|
<li>More room for a description in the OPTIONS dialog - possibly some
|
|
sort of help dialog could be provided for each option, like in
|
|
sysinstall.</li>
|
|
<li>Better handling of cases where OPTIONS are changed/added/removed
|
|
between upgrades.</li>
|
|
<li>The ability to depend on, or at least test, OPTIONS set in other
|
|
ports. Possibly it would be nice to enforce setting variables that are
|
|
depended upon when the port is being installed as a dependency.</li>
|
|
<li>Other types of OPTIONS controls - A text box in particular would be
|
|
useful for entering variables that need real values.</li>
|
|
<li>The possibility for mutually exclusive OPTIONS.</li>
|
|
<li>Bugfixes:
|
|
<ul>
|
|
<li>If you attempt to run make config for a port with
|
|
${PKGNAMEPREFIX} defined, the make config process will error out
|
|
with:<br>
|
|
===> Using wrong configuration file /path/options/file<br>
|
|
The solution is to define LATEST_LINK to be prefix-${PORTNAME},
|
|
but this should be done internally.</li>
|
|
</ul></li>
|
|
</ul>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong knowledge of shell and make code.</li>
|
|
<li>A basic understanding of the inner workings of the ports tree.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-ports-pkgtools"></a>
|
|
<h2>Package tools improvements</h2>
|
|
<p>The pkg_* tools, which deal with the installation of pre-build binary package
|
|
of ports, could do with a code cleanup or maybe even a rewrite from
|
|
scratch. Some features of the ports tree are not supported by the pkg_* tools,
|
|
e.g. versioned dependencies.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong knowledge of C code.</li>
|
|
<li>A basic understanding of the inner workings of the ports tree.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<!------------------------------------------------------------------>
|
|
<!- Security ->
|
|
<!------------------------------------------------------------------>
|
|
|
|
<a name="#p-auditkernel"></a>
|
|
<h2>Audit kernel event sources</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>
|
|
A number of kernel security subsystems, such as IPFW and pf, generate
|
|
security log data. This task involves identifying potential sources of
|
|
security event information in the kernel and modifying kernel subsystems to
|
|
log that information using the kernel security event auditing system.
|
|
User and programmer documentation of audit may be found on the <a
|
|
href="http://www.trustedbsd.org/docs.html">TrustedBSD Documentation Page</a>.
|
|
There are also extensive manual pages relating to audit in FreeBSD. This
|
|
project will require careful security analysis and kernel programming, and
|
|
will likely need some re-working of the kernel audit framework (which is
|
|
currently entirely focused on gathering user and kernel system call audit
|
|
data).
|
|
</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong C programming skills.</li>
|
|
<li>Familiarity with concurrent programming techniques.</li>
|
|
<li>General understanding of TCP/IP firewalls.</li>
|
|
<li>Willingness to read the CC/CAPP specification.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-distribaudit"></a>
|
|
<h2>Distributed audit daemon</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>Create a tool that manages per-machine audit records and submits them to
|
|
a central site for processing and long-term archiving/management. Ideally
|
|
with support for SSL (or the like) so they do not travel on the wire in the
|
|
clear.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong (portable) C programming skills.</li>
|
|
<li>Knowledge of the audit subsystem.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="#p-mac"></a>
|
|
<h2>Mandatory Access Control</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>
|
|
FreeBSD 5.0 was the first FreeBSD release to ship with support for Mandatory
|
|
Access Control (MAC), an access control technology allowing system
|
|
administrators to implement multi-level security, integrity protection, and
|
|
other "mandatory" policies. Policies may be compiled into the kernel, or
|
|
loaded as loadable kernel modules.
|
|
Later revisions of FreeBSD and the MAC Framework enhanced MAC support,
|
|
and additional policy modules were made available, such as a port of the
|
|
SELinux FLASK/TE framework available as a third party policy module.
|
|
However, many of the sample MAC modules included with FreeBSD are considered
|
|
experimental examples of what the technology can be used for, rather than
|
|
production policies.
|
|
For example, the Biba integrity policy can be deployed in production, but
|
|
requires significant tuning to do so effectively.
|
|
</p>
|
|
<p>
|
|
This task involves a general review of the MAC Framework and Policy modules,
|
|
with the goal of identifying improvement areas. It also involves specific
|
|
cleanups, optimizations, and completeness work on specific policy modules --
|
|
most importantly, the Biba and MLS sample labeled policy modules. Work there
|
|
includes improving memory overhead and efficiency; for example, moving from
|
|
allocating complete labels for every labeled object to referencing common
|
|
label storage where labels are identical, which occurs a great deal of the
|
|
time in most systems.
|
|
Other cleanups include moving towards a canonical/extensible on-disk label
|
|
storage format, adding regression tests, investigating interactions with user
|
|
applications, and writing documentation.
|
|
</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong C programming skills.</li>
|
|
<li>Familiarity with OS security policies, including discretionary and
|
|
mandatory access control.<li>
|
|
<li>Familiarity with concurrent programming techniques.</li>
|
|
<li>Willingness to read the CC/CAPP specification.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="#p-securityregression"></a>
|
|
<h2>Security regression tests</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>
|
|
FreeBSD is undergoing constant and active improvement to all of its critical
|
|
subsystems, from file systems to the network stack. With any change, there
|
|
is a risk of introducing bugs or regressions. The goal of this task is to
|
|
produce a security regression test suite, which encapsulates requirements
|
|
regarding system security properties and tests that they (still) hold. Areas
|
|
to test include file system access control, privilege, authentication,
|
|
cryptography, process containment, and more. There are some current tests
|
|
along these lines in the <a
|
|
href="http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/regression/">FreeBSD
|
|
regression test tree</a>, but they are both incomplete and and inadequate.
|
|
New tests must be created; existing tests must be completed and updated.
|
|
</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Strong C programming skills.</li>
|
|
<li>High tolerance for writing test code.</li>
|
|
<li>High tolerance for reading API specifications.</li>
|
|
<li>Rigorous and devious mindset.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<!------------------------------------------------------------------>
|
|
<!- Userland / Installation Tools ->
|
|
<!------------------------------------------------------------------>
|
|
|
|
<a name="p-bsdelftools"></a>
|
|
<h2>BSD-licensed ELF Tools</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:jkoshy@FreeBSD.org">&a.jkoshy;</a></p>
|
|
<p>Create BSD-licensed versions of ELF processing tools (e.g., <strong>nm</strong>
|
|
and <strong>strip</strong>) using the ELF(3) and GELF(3) API set in FreeBSD
|
|
-CURRENT.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Knowledge of C.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-noswitches"></a>
|
|
<h2>Build options improvements</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:netchild@FreeBSD.org">&a.netchild;</a>, <a href="mailto:gbell72@rogers.com">Gardner Bell</a></p>
|
|
<p>The new "delete-old" and "delete-old-libs" target in /usr/src for 6.1 and
|
|
-CURRENT should be extended to support the WITHOUT_* knobs, e.g.
|
|
WITHOUT_RESCUE or WITHOUT_CRYPT, and delete files which are covered by those
|
|
knobs. Some switches have already been <a
|
|
href="http://cvsweb.freebsd.org/src/tools/build/mk/OptionalObsoleteFiles.inc">covered</a>.
|
|
You can view a list of all switches and what effect they have <a
|
|
href="http://phk.freebsd.dk/misc/build_options/">here</a>.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Time to build and install the world several times.</li>
|
|
<li>A way to determine which files were not touched by an installworld.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-lint"></a>
|
|
<h2>lint(1) improvements from OpenBSD</h2>
|
|
<p>OpenBSD has some improvements to lint(1) which may be beneficial to
|
|
have.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of C.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-libprocnet"></a>
|
|
<h2>Libprocstat and libnetstat</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a></p>
|
|
<p>Create, similar to libmemstat, wrapper libraries to support monitoring and
|
|
management applications to avoid direct use of kvm. Three parts to the
|
|
project: for each of the above, add kernel support to export data in a less
|
|
ABI-sensitive way using sysctl, write a library to present the information
|
|
in an extensible way to applications, and update applications to use the
|
|
library instead of reaching directly into kernel memory / consuming sysctls.
|
|
The goal is to allow the kernel implementation to change without breaking
|
|
applications and requiring them to be recompiled, and to allow monitoring
|
|
functions to be extended without breaking applications. This should also
|
|
facilitate writing new classes of monitoring and profiling tools.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of C.</li>
|
|
</ul>
|
|
|
|
<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><a href="mailto:leeym@FreeBSD.org">&a.leeym;</a> has a port of
|
|
the <a href="http://sourceforge.net/projects/umem">Linux port</a>. He
|
|
is looking for someone who is interested in benchmarking, testing, or
|
|
evaluating his port.</p>
|
|
<p><a href="mailto:jasone@FreeBSD.org">&a.jasone;</a> has a benchmark
|
|
suite at <a
|
|
href="http://people.freebsd.org/~jasone/jemalloc/benchmarks/benchmarks.tbz">
|
|
here</a>. A description of the benchmark can be found in his
|
|
<a href="http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf">
|
|
jemalloc paper</a></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-prebind"></a>
|
|
<h2>Port prebind from OpenBSD</h2>
|
|
<p>The OpenBSD prebind is a secure implementation of prelinking that
|
|
is compatible with address space randomization. Prelinking allows to
|
|
speed up application startup when a lot of libraries are involved.
|
|
This should show a noticeable effect with e.g. GNOME/KDE.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good C knowledge (reading and writing).</li>
|
|
</ul>
|
|
|
|
<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><a href="mailto:m@FreeBSD.org">Markus Boelter</a> is <a
|
|
href="http://wiki.freebsd.org/MarkusBoelter">working</a> on a bundled
|
|
PXE installer as part of his BSDInstaller project withhin the Google Summer
|
|
of Code 2006. The PXE Installer is working but some non-PXE related issues
|
|
have to be solved before it can enter the tree.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good PXE knowledge.</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="p-regression"></a>
|
|
<h2>Regression testing system</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:netchild@FreeBSD.org">&a.netchild</a>, <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>Porting <a href="http://ltp.sf.net/">LTP</a> might also be a good idea.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>Good knowledge of scripting languages (Perl preferred).</li>
|
|
<li>Good knowledge of software testing.</li>
|
|
</ul>
|
|
|
|
<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>
|
|
</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-taroutmode"></a>
|
|
<h2>Tar output mode for installworld</h2>
|
|
<p><strong>Technical contact</strong>: <a
|
|
href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a>, <a
|
|
href="mailto:cperciva@FreeBSD.org">&a.cperciva;</a></p>
|
|
<p>Instead of installing using install, mkdir, mtree, etc, directly construct
|
|
a tarball. This would allow creating install distributions without root
|
|
access, as setuid etc would never hit the local disk. This would require
|
|
some retrofitting of our installation mechanisms.</p>
|
|
<p><strong>Requirements</strong>:</p>
|
|
<ul>
|
|
<li>No fear regarding our installation system.</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="../busdma/index.html">busdma and SMPng driver conversion
|
|
Project</a></li>
|
|
<li><a href="http://www.TrustedBSD.org/">TrustedBSD Project</a> and <a
|
|
href="http://wiki.FreeBSD.org/TrustedBSDTODO/">TrustedBSD TODO
|
|
list.</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>
|