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.
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.
If you have any non-technical questions about this list, please contact &a.netchild; and &a.joel;. Technical questions should be directed to the Technical contact for each project, or to the hackers mailinglist.
Fix MDFS lockups when using async operation modes. Revision 1.115 of md.c has a discussion of the problem.
Requirements:
Technical contact: &a.netchild;
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.
Goals:
Rohit Jalan has begun porting the NetBSD tmpfs to FreeBSD. The source and some benchmarks can be found here. Before it can enter the tree locking has to be added. There are also some bugs to take care of. Rohit has no time to work on it in the next months, any volunteer is welcome to continue his work.
Requirements:
The UFS2 file system in FreeBSD supports extended attributes. Extended attributes are meta-data associated with vnodes representing files and directories. Unfortunately dump and restore do not backup or restore such attributes. People interested in this should contact &a.mckusick;.
Requirements:
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.
Requirements:
Technical contacts: &a.mat;, &a.brd;
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.
Requirements:
Technical contacts: &a.netchild;, &a.ariff;
Requirements:
Technical contact: John Birrell
URL: Perforce repository, DTrace for FreeBSD
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.
Requirements:
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.
Requirements:
Technical contact: &a.sam;
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.
Requirements:
Technical contact: &a.netchild;
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 here.
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.
Requirements:
Technical contact: Attilio Rao
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.davidxu; has some work in progress in his sysenter branch in the perforce repository.
Requirements:
Technical contact: &a.philip;
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).
Requirements:
Technical contacts: &a.njl;, &a.bruno;
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 ACPI mailing list and &a.bruno; has some early patches.
Requirements:
Technical contact: Danny Braniss
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.
Requirements:
Technical contact: &a.imp;
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.imp; is available for review and coordination of committing.
Requirements:
Technical contact: &a.bms;
Requirements:
Technical contact: Emiliano Mennucci
References: The Pluggable Disk Schedulers SoC project, Patches
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.
Requirements:
Technical contact: &a.mux;
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.
Requirements:
Goals:
Requirements:
Technical contacts: &a.njl;, &a.bruno;
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.
Requirements:
Technical contact: &a.jhb;
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.
Requirements:
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.
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.
Requirements:
Technical contact: &a.mux;
URL's: csup homepage, CVSweb
&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:
Requirements:
Technical contact: &a.rwatson;
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.
Requirements:
Technical contact: &a.sam;
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.
Requirements:
Technical contact: &a.alfred;
Requirements:
Technical contact: &a.alfred;
Moving the lockd implementation into the kernel provides several key performance and semantic improvements.
Requirements:
Technical contact: &a.mlaier;
+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.
+Requirements:
+Technical contact: &a.phk;
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.
Wanted features (not sorted or prioritized):
Requirements:
Technical contact: &a.rwatson;, &a.gnn;
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.
Requirements:
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.
Requirements:
Technical contact: &a.sam;
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.
Requirements:
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.
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.
Requirements:
Technical contact: &a.erwin;
Make these more consistent. WITH_* should be user-settable variables while USE_* only is for internal use in the ports.
Requirement:
Technical contact: Gardner Bell
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:
Requirements:
The current OPTIONS infrastructure can be improved in several ways.
Requirements:
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.
Requirements:
Technical contact: &a.rwatson;
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.
Requirements:
Technical contact: &a.rwatson;
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 TrustedBSD Documentation Page. 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).
Requirements:
Technical contact: &a.rwatson;
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 FreeBSD regression test tree, but they are both incomplete and and inadequate. New tests must be created; existing tests must be completed and updated.
Requirements:
Technical contact: &a.rwatson;
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.
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.
Requirements:
Technical contact: &a.jkoshy;
Create BSD-licensed versions of ELF processing tools (e.g., nm and strip) using the ELF(3) and GELF(3) API set in FreeBSD -CURRENT.
Requirements:
Technical contact: &a.netchild;, Gardner Bell
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 covered. You can view a list of all switches and what effect they have here.
Requirements:
Technical contact: &a.rwatson;
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.
Requirements:
Currently FreeBSD supports only single byte collation. Multibyte collation support would be nice.
Benefits:
Requirements:
URL: The NDMP Initiative
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.
Requirements:
Technical contact: &a.brooks;
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.
Requirements:
Solaris 9 and later versions include libumem, a user
space slab allocator that includes debugging features we may want to
have on FreeBSD too.
Online references for libumem are (in suggested reading
order):
Requirements:
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.
Markus Boelter is working 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.
Requirements:
Technical contact: &a.netchild, &a.nik;
&a.nik; has written a regression test infrastructure using Perl. More of the regression tests should be made to work with libtap.
Porting LTP might also be a good idea.
Requirements:
Requirements:
Technical contact: &a.rwatson;
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.
Requirements:
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.
Requirements:
Additional projects may be found by browsing the FreeBSD Development Projects page. The most prominent projects are:
Do not forget to have a look at the other projects too or by viewing some of the recent Developer Status Reports.
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:
Additionally, there are a lot of interesting mailing lists that can be used when searching information about specific subjects.