Skip site navigation (1) Skip section navigation (2)

Site Navigation

FreeBSD list of projects and ideas for volunteers

Introduction

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 Alexander Leidinger or Joel Dahl. Technical questions should be directed to the Technical contact for each project, or to the hackers mailinglist.

Project ideas

File System

Kernel

Networking

Security

Userland / Installation Tools

Additional Information

Port the NetBSD tmpfs (efficient memory file system)

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:

  • Port the tmpfs file system.
  • Adopt the documentation (including the file system how-to)

Rohit Jalan has begun porting the NetBSD tmpfs to FreeBSD. More information about the current status and progress is available here.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A little bit of knowledge of the VFS subsystem.

Autofs

Technical contact: Alfred Perlstein

Create the autofs file system from a specification. Kernel transport and interaction with the "amd" automounter needs to be completed.

Requirements:

  • Knowledge of file systems and network file systems.
  • Good knowledge of C.

Implement Magic Symlinks

Technical contact: John W. De Boskey

Patches: http://people.FreeBSD.org/~jwd/magiclinks.tgz

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).

Andrey V. Elsukov has begun porting this to FreeBSD, and some initial patches for CURRENT can be found here. There is also some on-going development in Perforce.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Some file system knowledge.

Fix mdfs lockups when using non-sync operation modes

Rev. 1.115 of md.c has a discussion of the problem.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge of the VFS and VMA subsystems.

Extend dump/restore support for UFS2 to cover extended attributes

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 Kirk McKusick.

Requirements:

  • Knowledge of C programming.
  • Basic understanding of backup/restore procedures.

Make truss(1) able to work without procfs

Technical contact: Maxime Henrion

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.

Requirements:

  • C knowledge.
  • Understanding of kernel debugging interfaces (ptrace, procfs, ...).

Port the "Pluggable Disk Schedulers" SoC project to current/GEOM

Technical contact: Emiliano Mennucci

URL: The Pluggable Disk Schedulers SoC project, Patches

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.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge of GEOM (or interest in getting familiar with it).

Sync USB code with NetBSD

Mailing list: freebsd-usb@FreeBSD.org

There are various improvements and fixes to the USB code in NetBSD which have not found their way into FreeBSD yet.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Various USB devices and/or energy to let people on the USB mailing list test patches and listen to bug reports regarding those tests.

Document as many sysctls as possible

Technical contacts: Mathieu Arnold, Brad Davis

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. Mathieu Arnold has done some development in Perforce, in the mat_sysctl_cleanup branch.

  • Find every undocumented sysctl in the kernel.
  • Try to determine what this sysctl is for and document it.

Requirements:

  • Ability to read and understand foreign C code.

Document the sound subsystem

Technical contacts: Alexander Leidinger, Ariff Abdullah

  • Add sound subsystem related section 9 manual pages, so far no sound subsystem related manual pages exists.
  • 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 this template.
  • 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, ...).

Requirements:

  • Ability to read and understand foreign C code.
  • Documentation writing skills.

Syncing with the 4Front Technologies OSS v4 API

Technical contact: Alexander Leidinger

URL: 4Front Technologies

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:

  • Add the necessary interfaces.
  • Add appropriate code to the sound subsystem/drivers where possible.
  • 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.
  • Use the improved API in our userland programs where it is beneficial.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • At least one supported sound card.

Implement necessary kernel interface for 4Front Technologies ALSA to OSS wrapper (SALSA)

Technical contact: Alexander Leidinger

URL: 4Front Technologies, SALSA

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • At least one supported sound card.

Improve locking of the sound system

Technical contact: Ariff Abdullah

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of the FreeBSD locking methods.

Add High Definition Audio (HDA) support to our sound system

Technical contact: freebsd-multimedia@FreeBSD.org (mailing list)

URL: HDA Specification

  • Have a look at the specification.
  • Implement HDA support.

Some work has been done, but progress is slow. More manpower is needed. Stephane E. Potvin has begun implementing HDA support to our sound system and a patch is available here. This is very experimental, and should not be considered stable code.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • HDA sound card.

Implement a generic input device layer

Technical contact: Philip Paeps

The kernel is lacking a generic input device layer analogous to the Linux 'input core' layer. Having such a layer would make it easy to write e.g. touchscreen support (Philip Paeps has some work-in-progress regarding pointer devices and touchscreen support, but not enough time to also cover keyboard support or other generic features).

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.

Add locking to the CAM layer

Technical contact: Scott Long

Scott Long has been working on this for a while, and he has patches in Perforce.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge about SCSI.
  • A good understanding of the FreeBSD locking methods.

Implement iSCSI

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:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge about (i)SCSI/CAM.

Port DragonFly's process checkpointing

Technical contact: Bruno Ducrot

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.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.

Evaluate and perhaps port DragonFly's optimized MMX/XMM memcpy/bcopy/bzero/copyin/copyout code (this includes an FPU subsystem overhaul)

Interesting files in the DragonFly CVS are sys/i386/gnu/fpemul/fpu_system.h, sys/i386/i386/bcopy.s, sys/i386/i386/genassym.c, sys/i386/i386/globals.s, sys/i386/i386/machdep.c, sys/i386/i386/math_emu.h, sys/i386/i386/mp_machdep.c, sys/i386/i386/pmap.c, sys/i386/i386/support.s, sys/i386/i386/swtch.s, sys/i386/i386/trap.c, sys/i386/i386/vm86bios.s, sys/i386/i386/vm_machdep.c, sys/i386/include/asmacros.h, sys/i386/include/globaldata.h, sys/i386/include/md_var.h, sys/i386/include/npx.h, sys/i386/include/pcb.h, sys/i386/include/thread.h sys/i386/isa/npx.c, sys/i386/i386/bcopy.s and sys/i386/i386/bzero.s. A more detailed writeup can be found in this compressed file. 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).

Attilio Rao has begun porting this to FreeBSD, and he would like to receive some feedback.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge of at least i386/MMX/XMM assembly.
  • A good understanding of the FreeBSD SMP system.
  • Roughly 6 weeks of free time.

Evaluate and perhaps sync FreeBSD i386 boot code with DragonFly's boot code

Technical contact: John Baldwin

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.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge of i386 assembly.
  • Knowledge of BIOS interfaces.
  • Knowledge of low-level boot behavior.

Fix the CPU usage display in top for threaded processes

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.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of the FreeBSD SMP system.

Implement PCI-Hotplug support

Technical contact: Bruce M. Simpson

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of low-level access of the hardware.
  • A good understanding of the FreeBSD device drivers.

Port Solaris' DTrace

Technical contact: John Birrell, Devon H. O'Dell

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.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of the FreeBSD kernel.

Add amd64 native support to the Linuxulator

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 emulation mailinglist regarding the userland part of the linuxulator.

  • Determine a way how to distinguish between 32 bit and 64 bit applications when entering a system call.
  • Design and implement 64 bit support while keeping 32 bit support.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of how to do a clean room implementation of GPL'ed code (no copy & paste!).

Update the Linuxulator

Technical contact: Martin Cracauer

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.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Ability to closely observe system call tracing to spot subtle differences in the behavior of certain calls.
  • A good understanding of how to do a clean room implementation of GPL'ed code (no copy & paste!).

Annotate every assembler file [*.[sS]] with dwarf2 call frame information

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.

Requirements:

  • Knowledge of assembly code.
  • Knowledge of ".cfi_*" pseudo-ops to insert dwarf2 frame descriptors.

Suspend to disk

Technical contacts: Nate Lawson, Bruno Ducrot

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:

  • Good knowledge of C.
  • Understanding of the hardware/software interface.
  • A laptop that works with ACPI.
  • Kernel awareness.

Implement and profile various algorithms for powerd

Technical contacts: Nate Lawson, Bruno Ducrot

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 Bruno Ducrot has some early patches.

Requirements:

  • Basic C knowledge.
  • Laptop supported by cpufreq(4).

Dynamic module references

Technical contact: Sam Leffler

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:

  • Good knowledge of C.
  • Kernel awareness.

Add some more information in the ktrace(1)/kdump(1) output

Technical contact: Alexander Leidinger

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.

David Kirchner is currently working on this and the results will (most likely) be committed soon.

Requirements:

  • Knowledge of C.
  • Good knowledge of POSIX interfaces or how to use man(1).
  • No fear to look into the kernel sources.

Rewrite the in-kernel file system syncer and modernize the write behind code

References: mail #1, mail #2

Goals:

  • Change the syncer so it can sync out to multiple physical devices simultaneously.
  • 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).
  • 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).

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Some understanding of the VM system / buffer cache.

Cache detection support for sparc64

Technical contact: Alexander Leidinger (Page coloring)

Mailing list: freebsd-sparc64@FreeBSD.org

The current page coloring algorithm in the VM does auto tuning of the number of colors based upon cache size and associativity. On sparc64 the corresponding variables are not set. The goal of this entry is to detect the cache size and associativity (this information may already be available, or at least not much code has to be written) and set the corresponding variables.

Requirements:

  • Knowledge of C.
  • A sparc64 system to test/debug with.

Super tunnel daemon

Technical contact: Poul-Henning Kamp

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):

  • 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.
  • Plugin architecture for easy addition of further encapsulations.
  • Failover from one encapsulation to another.
  • Distinct configuration files for encapsulations which need to be configured (e.g. proxy, authentication, ...).
  • Possibility to disable installed encapsulations.
  • Print/log hints for protocols which require some configuration, e.g. telling the user to use keys and perhaps the ssh-agent for ssh.
  • Configurable additional plugin directories (for plugins installed via the ports collection).
  • Log how it is able to tunnel the traffic (this also makes it useful for finding unwanted holes in the configuration of a firewall).

Requirements:

  • Good knowledge of C.
  • Good knowledge about networks.

Implement missing csup features

Technical contact: Maxime Henrion

URL's: csup homepage, CVSweb

Maxime Henrion 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:

  • Add support for authentication.
  • Add support for shell commands sent by the server.
  • Add missing support for various CVSup options: -D, -a (requires authentication support), -e and -E (requires shell commands support) and the destDir parameter.
  • 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.

Requirements:

  • Strong knowledge of C.
  • Good knowledge of POSIX standards.
  • Ability to work with multi-threaded applications.

Add zeroconf (Rendezvous/Bonjour) support to FreeBSD

URL: NetBSD zeroconf SoC project

  • Find/write a suitable zeroconf implementation.
  • Add zeroconf support to the base system daemons.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.

NFS Lockd (improve semantics)

Technical contact: Alfred Perlstein

  • Improve the semantics of the NFS lockd in FreeBSD. Apple has made certain enhancements that can be leveraged in our code base.
  • Implement state recovery in the lockd.

Requirements:

  • Good knowledge of C.

NFS Lockd (kernel implementation)

Technical contact: Alfred Perlstein

Moving the lockd implementation into the kernel provides several key performance and semantic improvements.

Requirements:

  • Good knowledge of C.
  • Good understanding of NFS.
  • Good understanding of locking.
  • Good understanding of RPC.
  • Good understanding of kernel level networking.

Port Web100 to FreeBSD

Technical contact: Brooks Davis

URL: The Web100 project

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.

Requirements:

  • Good knowledge of C.
  • The features of Web100 need to be mapped into appropriate FreeBSD abstractions and integrated into the system.
  • The performance impact of these changes would have to be quantified before the changes could be introduced.
  • Good understanding of the TCP protocol.
  • Good understanding of kernel interfaces.

WPA2 preauthentication support in hostapd

Technical contact: Sam Leffler

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:

  • Good knowledge of C.
  • Wireless networking fundamentals.
  • WPA-capable wireless network setup.

IAPP preauthentication support in hostapd

Technical contact: Sam Leffler

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:

  • Good knowledge of C.
  • Wireless networking fundamentals.
  • Wireless network setup.

Bring wi(4) up to par with the current state of affairs in the WLAN infrastructure

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.

Requirements:

  • Knowledge of C.
  • No fear to "use the source Luke" and to have a look at undocumented parts of the kernel.
  • At least one wi(4) card and one other wireless device to test against.

"Flight mode" for the loader

Not every airline allows to use radio transmitters like WLAN-NIC's in airplanes (yet). The goal of this entry is to provide an entry in the loader which prohibits drivers for devices which transmit radio signals to attach to the device. One way of providing this functionality would be to add a menu entry to the loader which sets a "flight mode" loader tunable which would have to be queried by every driver which is able to transmit radio signals to decide if the normal operation is allowed or if the device has to be disabled. The loader-menu should be able to detect this tunable in loader.conf and indicate which way of booting is the current default (in case the user adds it there to be on the safe side in the airplane).

Requirements:

  • Knowledge of C (changing the drivers to respect the tunable).
  • Knowledge of forth (changing the loader-menu).

RFC3442 support

Technical contact: Ed Maste

URL's: RFC3442

Add support for RFC3442, the Classless Static Route option, to the DHCP client. The original DHCP specification includes a route option but it supports only class-based routes, which are not very useful today. RFC3442 adds support for specifying the netmask width for each static route. Note that the ISC dhcp server does not natively support RFC3442, but custom options of arbitrary byte strings can be encoded in its configuration file.

Requirements:

  • Good knowledge of C.
  • Routing knowledge.

Small sysinstall renovation

  • Ask for network configuration before install - so you do not have to configure the net twice.
  • Make a guess of the timezone based upon country & keyboard.
  • 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.
  • Other usability improvements not yet thought of.

Requirements:

  • Good C knowledge (reading and writing).
  • No fear regarding "naturally grown" code.

Extract the partition and slice table editor from sysinstall

Technical contact: Alexander Leidinger

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. Alexander Leidinger has some working code which will (most likely) be committed after 6.1 is released. The code is nearly finished, so no more help is needed at the moment.

Requirements:

  • Knowledge of C.

Bundled PXE Installer

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.

Requirements:

  • Good PXE knowledge.

Improve our regression testing system

Technical contact: Nik Clayton

Nik Clayton has written a regression test infrastructure using Perl. More of the regression tests should be made to work with libtap.

  • Many of the existing tests should be moved from using assert() to using ok() and friends from libtap.
  • More regression tests should be written.

Requirements:

  • Good knowledge of scripting languages (Perl preferred).
  • Good knowledge of software testing.

Tracking performance over time

Technical contact: Brooks Davis

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.

Write a NDMP data server

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.

  • Evaluate the existing revisions of the NDMP standard.
  • Choose an appropriate revision (after checking of supported versions in commercial backup systems).
  • Implement at least a NDMP data server.
  • Bonus: implement a NDMP tape server (to allow attached tapes to be used).

Requirements:

  • 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).
  • Good knowledge of a programming language which is included in the base system.
  • Knowledge about UFS snapshots.

Add support for WITHOUT_* switches to "make delete-old"

Technical contact: Alexander Leidinger

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:

  • Time to build and install the world several times.
  • A way to determine which files were not touched by an installworld.

Move HESIOD out of libc into a NSS module

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.

Benefits:

  • Less code linked to every application.
  • Less complexity in libc.
  • More flexibility for system administrators.
  • More consistent use of subsystems (NSS).
  • 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).

Requirements:

  • Knowledge of C.

Move NIS/YP out of libc into a NSS module

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.

Benefits:

  • Less code linked to every application.
  • Less complexity in libc.
  • More flexibility for system administrators.
  • More consistent use of subsystems (NSS).
  • 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).

Requirements:

  • Knowledge of C.

Import NSS LDAP support into the base system

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.

Benefits:

  • Better user management support in large scale environments out of the box.
  • Better user management support in heterogeneous environments out of the box.
  • Allows further work for better integration with Active Directory.
  • Allows further work to enhance the FreeBSD installation process (guided configuration of the LDAP part).

Requirements:

  • Knowledge of C.
  • Knowledge of NSS and LDAP.

Projects at FreeBSD.org

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.

Technical contacts

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.