• IdeasPage

FreeBSD Project "ideas" List

Over the years, the FreeBSD Project has built up a list of ideas for implementation work that seems like it might be a good idea, but no hands are available to do it. If you would like to contribute to the FreeBSD Project, you might peruse this list to get a sense of the kinds of work available to do. Obviously, contributions are not limited to this list!

Please do contact us before starting on it though -- sometimes items remain on the list after they are completed, and sometimes they are just ideas, rather than a recipe for success. Searching our mailing list archives may turn up the discussions leading to ideas being put on the list. Frequently the initial goal would be to simply investigate the idea, rather than produce code. Many project ideas list contacts, who it is worth sending an e-mail. Otherwise (and perhaps as well), send e-mail to our hackers@ list.

We have marked potential Google Summer of Code projects in the list; search for "Summer of Code" in the page to find them! It is especially important that Summer of Code applicants contact idea owners early so that they can get feedback during the application process. These projects are not restricted to GSoC students, of course.

Embedded Projects

Reduced FreeBSD kernel size for embedded

Contact Info

Technical Contact: imp@

Description

The FreeBSD kernel has been optimized over the years for a server or workstation environment. Memory is plentiful in these environments, so little attention was given to the size of the kernel. There's a number items in the kernel that can be made optional without reducing affecting the functionality needed in an embedded environment. These include things like not compiling in strings into the kernel, less agressively inlining code, making some non-optional features optional and investigating compile time flags. This task requires identifying potentially optional kernel content and building the infrastructure to make that content optional.

Requirements

• Strong C language programming skills.
• Understanding of system calls and general kernel architecture.

NAND Flash driver support

Technical Contact: imp@ andrew@

Description

Add support for NAND flash devices.

Requirements

• Good C programming skills
• Ability to understand FreeBSD subsystems like geom, device, etc.

Make creating a bus easier

Technical Contact: imp@

Description

There's about a dozen busses in the tree now that manage resources and activate children. They are far too hard to create. We need to abstract out the basics for these buses and provide a way to allow these buses to be a subclass of this new base class.

Requirements

• Good C programming skills

• Good knowledge of the NewBus configuration system in FreeBSD

Variable hints

Contact Info

Technical Contact: imp@

Description

Often times in the embedded world, you know what kind of built-in devices are on a SoC (System on a Chip) only because you know the specific model of that SoC. It is desirable to have a mechanism that code on these machines can use to load one of several sets of hints, which can then be used to populate the bus.

Requirements

* Good C programming skills

ARM cleanup

Contact Info

Technical Contact: imp@

Description

Adding a new board to the arm code is a lot harder than it needs to be. A lot of benefit could be had by creating tables for memory ranges, etc, and having more generic initialization code. Much of this can also be Machine Independent (MI).

Requirements

• Good C programming skills
• Good refactoring skills

PPC/ARM/MIPS bring up

Contact Info

Technical Contact: imp@

Description

There's a number of SoCs that are in consumer grade routers, etc that have chips that are supported by FreeBSD, or nearly supported by FreeBSD. Pick one and bring FreeBSD up on it. Integrate it into the tree.

Requirements

• Good C programming skills
• Good kernel debugging skills

Overhaul the config system

Contact Info

Technical Contact: imp@

Description

Right now the kernel is built twice: once for the static modules in the kernel, and once for the dynamically loaded. There's also inconsistent dependency tracking. We should fix this. Bikeshed included, along with three colors of paint.

Requirements

• Good C programming skills
• Good kernel debugging skills
• Ability to withstand Bikesheds

File System Projects

FAT (msdosfs) infrastructure work (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: rwatson@

Description

The FreeBSD FAT implementation, msdosfs, offers scope for a number of projects:

• General cleanup.
• Introduce appropriate locking to make the file system operate without the Giant lock (MPSAFE).

It is unclear to what extent the last of these items, arguably the most useful, might require modifying surrounding infrastructure such as BIO, GEOM, and VM.

Requirements

• Strong C programming skills.
• Familiarity with concurrent programming techniques.
• Familiarity with FAT file system layout.
• Familiarity with the idea of a virtual file system and virtual memory.

Improve the performance of dump/restore

Description

A performance evaluation of the split cache (as is) and an unified cache (like e.g. NetBSD) would be interesting. More details in this mail to the hackers mailing list. Additional improvements are welcome too.

Requirements

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

Extend UFS2 with on-disk indexing (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: dwmalone@

Description

The section 8.3 Naming of the book Design and Implementation of the FreeBSD Operating System describes the current approach of name lookups in UFS2 and a possible extension/improvement by utilizing on-disk indexing in a backward compatible way. While dirhash has eliminated many of the performance problem associated with UFS directory lookups, it still has to build an index on each access. On-disk indexing would improve this situation. Another possible improvement would be to make dirhash's memory usage dynamic, rather than having a fixed memory limit.

Requirements

• Knowledge of C programming.
• Basic understanding of filesystems.
• The book Design and Implementation of the FreeBSD Operating System.

UFS improvements

Fast consistency checking for the Solaris file system

A co-locating fast file system for UNIX

Description

While FreeBSD's FFS implementation is pretty much state-of-the-art with the addition of SUJ, there are some improvements that can still be made. In 1998, as part of some fsck improvements, SUN's NETRA NFS group developed a hotspot allocator and a bmap cache for the sync mode that greatly improved NFS performance. Greg Ganger also proposed other strategies that would be useful in addition to softupdates, especially when working with small files. Such enhancements can be useful for special situations and must be well understood and benchmarked for future inclusion in UFS.

Requirements

• Ability to read and understand foreign C code.
• Ability to write C code.
• Knowledge of the UFS/UFS2 filesystem internals.

MDFS lockups

Description

Fix MDFS lockups when using async operation modes. Revision 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.

MPSAFE filesystem work (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: kib@

Take a filesystem and MPSAFE it. e.g. ntfs, coda, etc. See also: MPSAFE_VFS

Porting HFS+

HFS Wiki FreeBSD 5.3 HFS port

Description

The Hierarchical File System was developed by Apple Inc. for use in MacOS. With the Release of MacOS X it received many new features, and the source code was made available as part of XNU. An initial port was made and although it was subsequently abandoned, it would be excellent reference material for an updated port.

Requirements

• Strong knowledge of C.
• Understanding of FreeBSD's filesystem interfacing and VFS.

Dynamic VFS namecache

Slackathon 2009: Hacking VFS in OpenBSD

Description

Analyse if it possible to change our namecache in a similar way as done in OpenBSD (see ''OpenBSD's tech ML - vfs cache diff''). If possible adapt our namecache accordingly and run benchmarks (speed but specially memory usage) to determine if such a modification is an improvement for FreeBSD or not.

Requirements

• Strong knowledge of C.
• Understanding of kernel debugging.
• Knowledge of correct benchmarking.

Port NiLFS to FreeBSD

Description

The NiLFS is a file system similar to the BSD LFS (and in some features to ZFS and Flash file system). The project would start (probably but not necessarily) by porting the NetBSD read-only implementation of the NiLFS to FreeBSD and continue by implementing the write support. The practical goal of the project would be to have a read-write NiLFS port which passes FreeBSD's fsx and fstest regression tests.

Requirements

• Strong knowledge of C.
• Understanding of file systems and VFS kernel interfaces
• Understanding of kernel debugging.

Finish porting FUSE to FreeBSD (GSoC)

Suggested Summer of Code 2011 project idea

Contact Info

Technical Contact: ivoras@

Description

The FUSE kernel module was partially ported by a previous Summer of Code project as fuse4bsd. The port is reasonably complete but suffers from stability issues which make it unusable for day-to-day use. This project would continue that port. The practical goals of the project would be to identify the issues in the port which cause crashes and memory corruption, fix them, update the port to newer version of FUSE, and fix the module so that the file system passes FreeBSD's fsx and fstest regression tests on at least sshfs.

Requirements

• Strong knowledge of C.
• Understanding of file systems and VFS kernel interfaces
• Understanding of how FUSE works from the user side
• Understanding of kernel debugging.

Kernel Projects

Teaching DDB to speak CTF (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: rwatson@

Description

DDB is FreeBSD's built-in kernel debugger, providing rudimentary on-console debugging support: initial crashdump analysis, lock analysis, breakpoint management, data structure inspection, basic scripting, as well as the ability to switch to remote GDB. Over the years, DDB has become tightly integrated with a number of our kernel subsystems, learning about printing out lock information, having "pretty printers" for several important kernel data types, etc. However, DDB has suffered from a lack of automatic access to contextual debugging information: it can inspect the kernel symbol table, but to print a data structure it has to be explicitly taught about the data structure. This project idea is to teach DDB how to use the CTF data used by DTrace to keep track of kernel data types. In theory, DDB could use this same information to create automatic pretty printers for all kernel data structures, rather than requiring explicit code for each type.

Requirements

• Strong knowledge of C.
• Experience working with DTrace and debuggers (could be gained while doing the project).
• Ideally, some experience debugging kernels, or at least, system software.

Timecounter Performance Improvements (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: kris@

Description

The gettimeofday syscall is a performance bottleneck in certain applications. An approach taken by other operating systems is to export the time counter to userland via a shared page, and to update it periodically (a prototype implementation is available). For some time consumers this is sufficient resolution. Other consumers need higher resolution. On the x86 architecture the TSC timecounter can be read from userland. However depending on the hardware there may be issues with synchronization between CPUs, as well as interaction with CPU frequency changes. With care it can be used as a delta against the timestamp updated by the kernel to provide improved resolution and avoid the need for the syscall.

Automated kernel crash reporting system (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: delphij@, howardsu@

Description

In some recent operating systems, it is common that crashes are automatically reported to its vendor, which is very helpful for finding hidden problems that can not be easily triggered by usual test cases. Newer GNOME applications also have similar functionalities.

This project would consist two parts. One is some improvements over the current savecore rc.d script to teach it how to collect necessary information (of course, automatic reporting has to be explicitly enabled by individual system administrators, and should have at least three options: not to send out anything at all as a default, send out after administrator confirmation, and automatically send all necessary information). The FreeBSD kernel in 8-current has the textdump feature which may be interesting to use for this part

Another part after the first one is finished is the server side one, which will keep a database of backtraces where similar (call stack minus addresses) reports are kept together and be considered as a "vote", to make it possible for developers and release engineers to focus on the most commonly triggered issues.

Requirements

• Strong knowledge of C.
• Understanding of kernel debugging.
• Knowledge about web application as well as database.
• Understanding of user privacy protection.

Avoiding syscall overhead (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: attilio@, kris@

Description

setproctitle() calls are a serious performance bottleneck in a default pgsql configuration (they are called at least once per query, which might be thousands of times per second - I measured a performance impact of about 33% on sysbench).

One idea for avoiding the syscall (and global sysctl lock) overhead for this kind of thing would be a memory page shared between kernel and userland which libc could read/write to access things like the process title. There are potentially many other data values that could be optimized by a similar method. This is presumably a well established technique in other OSes.

This project requires mentoring/review/planning with someone with significant VM experience to make sure this approach works properly. Done incorrectly, this could result in fairly massive security holes, performance issues (perhaps not visible in simple benchmarks), etc.

Work is currently in progress on this and is undergoing review. It is not complete, but interested parties should contact Attilio before beginning work.

Requirements

• Strong knowledge of C.
• Understanding of kernel VM.

CPU online/offline project (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact: jhb@

Description

The project would need to extend the current CPU states of absent and present to include absent, offline, and online. A set of event handlers (probably using EVENTHANDLER(9)) will need to be created to allow subsystems to be notified of CPU state changes. At a minimum, the functionality of the current 'hlt_cpus_mask' should be reimplemented in both the 4BSD and ULE schedulers using this mechanism. Note that the ability to disable all but one thread within a core must still be supported easily. (This is currently done on x86 via the machdep.hyperthreading_allowed sysctl.) Each subsystem that uses CPU_ABSENT() will need to be evaluated to see if it needs updating to handle online vs offline CPUs. Further improvements may include teaching UMA to free per-CPU buckets when a CPU is taken offline.

Requirements

• Strong knowledge of C.
• Experience with multi-threaded programming.
• Experience with kernel programming.

Document all sysctls

Contact Info

Technical Contact: mat@, brd@

Description

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

Contact Info

Technical Contacts: netchild@

• 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 http://people.freebsd.org/~cg/template.c.

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

• The page soundsystem which documents everything related to the sound subsystem in FreeBSD has been created.

Requirements

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

DTrace

Contact Info

Technical Contact: rwatson@

Homepage: 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.

• We need a clean CTF implementation for FreeBSD to avoid the license (CDDL) that Sun has on their code. A specification about the file format needs to be written, and someone who never looked at the Sun code (and doesn't while doing the work) would have to implement that and write tests for the implementation.

• We should also have a port of Solaris' Modular Debugger MDB that has the ability to process in-kernel Dtrace buffers.

Requirements

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

DWARF2 call frame information

Suggested Summer of Code 2011 project idea

The DWARF Debugging Standard

Description

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

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

Kernel support for linux DVB device drivers

Suggested Summer of Code 2009 project idea

Technical Contact: luigi@

Description

In early 2007 we started a project to support building Linux device drivers on FreeBSD. This was done through an in-kernel emulation layer, which implements part of the linux kernel API on top of the FreeBSD kernel API. The initial implementation was good enough to support a few USB webcam drivers, and is documented here. The code is actually available as a port, devel/linux-kmod-compat, and a popular driver that uses this infrastructure is multimedia/linux-gspca-kmod.

We would like to use a similar approach to add support for DVB devices, which are widely supported in Linux but not in FreeBSD. In particular we expect the project to provide, within the FreeBSD kernel, enough of linux compatibility to build the core components of the drivers/media/ linux kernel, and then a few device drivers including one for a PCI DVB card (e.g. saa7134-based).

Before the start of the project, a Summer of Code applicant is expected to i) become familiar with the approach used by linux-kmod-compat; ii) set up a proper test environment, with a couple of DVB devices supported by linux, and a working linux installation so that one can compare results; iii) become familiar with the architecture of the linux code in drivers/media. Probably the attention should be focused in PCI devices, because at this stage the USB stack is in a transition phase and would pose some additional difficulties.

Expected results are a working porting infrastructure, a working linux-dvb-kmod device driver, and a working application to demonstrate that the driver is working as expected. We suggest to look at "kaffeine" for which a FreeBSD port already exists.

Info: USB based DVB devices are already supported by the multimedia/webcamd port on FreeBSD 8.x+ and work is underway to enable the use of them from linux programs (native FreeBSD programs are alaready able to use them).

Fast syscall support for FreeBSD/i386

Technical Contact: attilio@, jeff@

Description

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. davidxu@ has some http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064403.html in his sysenter branch in the perforce repository.

Requirements

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

References: Sysenter Based System Call Mechanism in Linux 2.6

Interactive Splash Screen

Improve upon / replace the existing static VESA splash screen support in FreeBSD, with a script-driven back-end, which allows animation in the loading graphics. This would greatly improve the bootup experience for desktop users, while providing graphical feedback to the startup of the kernel / system services. Additionally this could be used to replace the beastie.4th menu, with a VESA driven graphical loader screen.

PCI-Hotplug support

Technical Contact: bms@

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 FreeBSD device drivers.

Collective limits on set of processes (a.k.a. jobs)

Technical Contact: gabor@, brooks@

In SGI's Irix operating system, there is a concept of a job which is a collection of processes. These processes share a set of resource limits similar to those accessible through the set/getrlimit and getrusage system calls. Schedulers such as Sun Grid Engine currently implement tracking the processes that make up a job and enforcing collective limits on them in an adhoc manner. Having first class kernel support would be useful.

It seems most likely that implementing something like the Irix interface would be the most useful approach since that would enable us to leverage existing code. Implementers will need to make sure that the job construct has no negative performance implications when not enabled (ideally, processes that are not part of jobs should be unaffected) and quantify the impact on perfomance when enabled.

References: http://techpubs.sgi.com/library/tpl/cgi-bin/browse.cgi?cmd=search&coll=0650&db=man&pth=&srch=jid_t&searchpth=man&rpt=20

Requirements

• Good knowledge of C.
• Kernel awareness.
• Ability to implement functionality from interface specifications.

(Re)implement the BFS scheduler in FreeBSD

Suggested Summer of Code 2011 project idea

The BFS scheduler is a relatively simple scheduler curiously similar to the 4BSD scheduler but apparently even simpler and with improvements for machines with a relatively small number of CPUs (<= 16). It would be good to see how it compares to current FreeBSD schedulers, which are fairly complex.

Requirements

• Good knowledge of C
• Knowledge of what system process scheduling actually is
• Ability to do a "clean room" reimplementation of the GPL code as BSD code

Geom-based Disk Schedulers

Suggested Summer of Code 2009 project idea

Technical Contact: luigi@freebsd.org

In a 2005 GSoC project, "Pluggable Disk Schedulers", Emiliano Mennucci explored the feasibility of pluggable disk schedulers for FreeBSD. The project was successful, but we could not explore certain approaches (e.g. "anticipation", where requests are delayed hoping that some future ones can served without a seek) due to architectural limitations the kernel had at the time.

Since then, the GEOM infrastructure has become available on FreeBSD for interacting with disk I/O requests. GEOM has enabled us to work on disk schedulers in a much more flexible way, allowing a much faster development of disk scheduling algorithms. With Fabio Checconi, we have developed a prototype implementation of some anticipatory schedulers, see GEOM_SCHED.

http://info.iet.unipi.it/~luigi/FreeBSD/#geom_sched works within the geom layer, i.e. above the device driver where queueing of requests may actually occur. The way GEOM_SCHED does scheduling is by limiting the number of outstanding requests to the device, and the performance implications of this approach need to be measured. An alternative approach is to push the scheduler (using the same algorithms developed in GEOM_SCHED, and most likely the same code) within the device drivers. This less general (as it needs to be replicated in all drivers) but it may be an interesting thing to do e.g. for some popular device drivers such as ATA.

The proposed SoC work can address one or more of the following aspects:

• implement suitable classifiers for disk requests;
• implement techniques for the auto-tuning of the scheduler parameters;
• measure the performance implications of doing scheduling above the device driver, and possibly design and implement a suitable mechanism to push the GEOM_SCHED module within the device driver itself.

Ultimately, we expect to end up with a production quality subsystem for use in FreeBSD.

References: The Pluggable Disk Schedulers SoC project, http://www.happyemi.org/hybrid/

Requirements

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

Remove procfs dependencies

Technical Contact: cognet@

Someone needs to finish the support for PT_SYSCALL in the ptrace() subsystem and remove the need for procfs in gcore.

Requirements

• C knowledge.
• Understanding of kernel debugging interfaces.

Suspend to disk

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.

Sync FreeBSD i386 boot code with DragonFly

Technical Contact: 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

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

EFI support for FreeBSD/i386 and FreeBSD/amd64 (GSoC)

Suggested Summer of Code project idea

Technical Contact: rpaulo@

Finish EFI support on the i386/amd64 ports. Final work should be able to boot a FreeBSD kernel into single user mode, at least.

Requirements

• Good knowledge of C.
• Deep understanding of the boot process and EFI.
• A system running EFI 1.0 (Intel Macs, for example)

Networking Projects

csup improvements

Technical Contact: lulf@

URL's: http://mu.org/~mux/csup.html, http://www.freebsd.org/cgi/cvsweb.cgi/projects/csup/

csup is a port of the cvsup high-speed CVS repository replication application from the original Modula-3 to the C language. It is now distributed with FreeBSD, but is missing some important features that would make useful projects to work on:

• Working rsync support.
• Optimize rcsfile handling.
• Create a library out of the ports that might be of use in a C language csupd.
• Add support for shell commands sent by the server.
• Add missing support for various CVSup options: -D, -e and -E (requires shell commands support) and the destDir parameter.
• Work on a new csupd.

Requirements

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

Multiqueue BPF support and other BPF features (GSoC)

Suggested Summer of Code 2011 project idea

Technical contact: Robert Watson Technical Contact: rwatson@

The Berkeley Packet Filter (BPF) allows packet capture filters to be compiled into a bytecode that is either interpreted by a kernel virtual machine, or compiled into native machine code via a JIT and executed in in-kernel. Historically, the origin of packets has been the network interface, with each (synthetic) BPF device attached to exactly one NIC as requested by the application (for example, tcpdump). However, network interfaces have become significantly more complicated, and BPF has had to grow to support new features, such as Data Link Types (DLTs), in which BPF devices can tap network processing at different layers. This task would involve teaching BPF about a further dimension in network interface complexity: multiple input and output queues.

Modern 10gbps, and even 1gbps, network cards support multiple queues for various reasons: at first quality of service (QoS) differentiation in processing, but now especially to improve parallelism in network processing by distributing work to many CPUs on input. This same technica can also accelerate packet capture, but BPF currently doesn't know this. In this project, BPF would be enhanced to be aware of individual input and output queues on a NIC, which means providing network stack abstractions for these concepts, visible today only within device drivers. Userspace threads might then use enhanced ioctl(2)s to query the set of available queues and attach to one or more. Applications seeking maximum parallelism could open (n) devices, attaching each to a queue, and executing with appropriate CPU affinity. Ideally this would involve neither lock nor cache line contention throughout the entire stack, from device driver to userspace delivery.

Requirements

• Strong knowledge of C.
• Experience with multi-threaded programming.
• Experience with kernel programming.
• Familiarity with the TCP/IP protocol suite.

TCP/IP regression test suite (GSoC)

Suggested Summer of Code project idea

Technical Contact: rwatson@, 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. This project would build on previous work in this area, please contact the project owners for more information and references to that work.

Requirements

• Strong TCP/IP knowledge.

WPA2 preauthentication in hostapd

Suggested Summer of Code 2009 project idea

Technical Contact: adrian@, 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

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

802.11 Fuzzing and Testing (GSoC)

Suggested Summer of Code project idea

Technical Contact: adrian@, sam@

Build a "packet fuzzer" tool that can be used to build test suites to improve reliability of the 802.11 code against garbage data. There are various tools out but we're not aware of any good ones that work with 802.11 and are generally available. The basic idea is to write a packet injector/playback tool that's driven by a scripting language. Then you need to build up a database of test cases. It's also possibly important to do time-based playback.

Requirements

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

SCPS, Space Communication Protocol Standards

SCPS is a protocol suite designed to allow communication over challenging environments. Originally developed jointly by NASA and DoD's USSPACECOM, these protocols are used for commercial, educational, and military environments. A student project in this area would involve implementing various network protocols according to specification (SCPS File Protocol, similar to FTP; SCPS-Transport Protocol, based on TCP; and others.)

Note that European Space Agency has now an ESA Summer of Code in Space program and while FreeBSD is not a mentoring organization, interested students could motivate such a process.

References: Consultative Committee for Space Data Systems

Implement TCP UTO

Suggested Summer of Code 2011 project idea

Part of Summer of Code 2009

Technical Contact: rpaulo@

Implement TCP UTO (User Timeout Option) as defined by RFC 5482.

Requirements

• Good knowledge of C and TCP.
• Able to understand the FreeBSD TCP/IP stack.
• A testbed with at least two machines.

Ports Projects

Parallelization in the Ports Collection

Part of Summer of Code 2008

Technical Contact: pav@

Add locking of write access to PKG_DBDIR (/var/db/pkg), to allow several port builds run in parallel without clobbering the package data. Should be done both in makefiles and in C tools like pkg_install and pkg_delete. A simple flock(2) approach over the whole database comes to mind.

The next step is the parallelization of dependency building. Have the port build it's dependencies in parallel, automatically depending on number of CPUs in the machine, or manually specified by user (make -j3 install clean). Some kind of split screen should be devised, so user can easily watch the process and interact with it (make config screens, for example). Attention must be paid to prevent deadlocks.

Allow for situation when two ports want to build and install common dependency. One of the ports have to wait on the other to install it before proceeding.

Requirements

• Strong knowledge of make and shell code.
• Strong knowledge of C code.
• Good understanding of the inner design of the Ports Collection.

Ports license auditing infrastructure Part of Summer of Code 2008

Technical Contact: kris@, brooks@

Develop and deploy infrastructure for annotating license conditions that apply to third party software in the ports collection. For example, identifying ports provided under the GPL version 3 license, or under licenses that do not permit redistribution or which impose non-standard requirements. Part of this project will involve exploring methods for automatically classifying licenses using HP's fossology tool (http://www.fossology.org/) or other mechanisms.

Requirements

• Familiarity with bsd.port.mk and related ports collection infrastructure.

Complete (a.k.a. Fat) packages

Suggested Summer of Code 2009 project idea

Contact Info

Technical Contact: brooks@

Description

When bootstrapping systems it would be useful to be able to create a single package file that contains one or more packages and all the required dependent packages. This is conceptually similar to, but different from PC-BSD's PBI package format. PBI's contain a private copy of all dependencies, fat packages would contain each individual package and once installed it would be as though each package was individually installed in the usual manner.

This project would consist of additions to the pkg_tools to support creation and installation of a new package file format and to ports to build these packages.

Requirements

• Strong knowledge of C code.
• A basic understanding of the inner workings of the ports tree.

Security Projects

Distributed audit / log shipping daemon

Technical Contact: rwatson@ WIP: DistributedAuditDaemon

Create a tool to securely and reliably ship log files to remote hosts. The main focus is to manage per-machine audit records and submit 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

• Strong (portable) C programming skills.
• Knowledge of the audit subsystem.
• OpenSSL knowledge a plus.

Mandatory Access Control (GSoC)

Suggested Summer of Code project idea

Technical Contact: 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

• Strong C programming skills.
• Familiarity with OS security policies, including discretionary and mandatory access control.
• Familiarity with concurrent programming techniques.
• Willingness to read the CC/CAPP specification.

Path-based file system MAC policy (GSoC)

Suggested Summer of Code 2011 project idea

Technical Contact: rwatson@, trustedbsd-discuss@TrustedBSD.org

The TrustedBSD MAC Framework makes it easy to extend the FreeBSD kernel security model using pluggable modules, which has provided support for "traditional" mandatory access control, as well as allowed a number of companies to build local security policy extensions for workstation, server, and appliance products; one such example is Apple's "Seatbelt" policy for Mac OS X. However, the base system MAC policies are difficult to use, primarily because they either don't extend security meta-data (ugidfw) or they require extensive labeling (Biba, MLS). This project idea involves crafting a new OS security policy extension along the lines of ugidfw, the file system firewall, but using path names instead of existing file properties to manage protection. This requires careful thinking about what a file system path "is" in the UNIX environment, as well as regarding what sorts of policies would be useful.

Requirements

• Strong C programming skills.
• Familiarity with OS security policies, including discretionary and mandatory access control.

Security regression tests (GSoC)

Suggested Summer of Code project idea

Technical Contact: 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 http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/regression/, but they are both incomplete and and inadequate. New tests must be created; existing tests must be completed and updated.

Requirements

• Strong C programming skills.
• High tolerance for writing test code.
• High tolerance for reading API specifications.
• Rigorous and devious mindset.

A New Audit Parsing API (GSoC)

Suggested Summer of Code project idea

Technical Contacts: rwatson@, trustedbsd-audit@TrustedBSD.org

The current OpenBSM audit parsing API has a number of limitations, not least that it can't handle little endian BSM records that may come from Solaris x86 systems, in terms of ABI robustness in the presence of new record types, ability to process trails generated non-locally in terms of supporting uid/gid->name translation, and in terms of incrementally processing a byte stream from, for example, socket sources without using the C FILE API.

This task would consider existing audit parsing APIs in the industry, including POSIX.1e, relevant Open Group specs, and in-use APIs on other systems such as Solaris, Linux, Windows NT, and others, in order to first identify an existing candidate API or design a new candidate API, then implement the API and adapt existing audit applications to use it. The task would also document the API using man pages, create an audit parsing tutorial document, create a test suites, and require interaction with the OpenBSM and FreeBSD communities to identify audit parsing requirements.

If successful, the results of this work would be integrated into OpenBSM, the open source BSD-licensed audit framework shipped with FreeBSD and Mac OS X.

Requirements

• Strong C programming skills.
• Past coursework or reading in the area of computer security.

Linux to BSM Conversion Tool (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contacts: rwatson@, trustedbsd-audit@TrustedBSD.org

Description

The BSM (Basic Security Framework) audit trail format is the de facto industry standard for portable operating system audit trails, being supported on Solaris, FreeBSD, and Mac OS X. However, many other audit trail formats exist that are less portable, including audit trail formats local to Linux.

This task would create BSD-licensed conversion tools to import audit trails from other systems and convert them to BSM format so that they can be inspected and managed using the OpenBSM tool set. This would require the creation of BSD-licensed parsers for audit trail formats of interest, designing and documenting a semantic mapping to the BSM trail format, and writing conversion utilities using the new parsers, semantic mapping, and BSM generation routines in OpenBSM. A key part of this work would be to rigorously understand and document the mapping and its limitations. A test suite is also required.

If successful, the results of this work would be integrated into OpenBSM, the open source BSD-licensed audit framework shipped with FreeBSD and Mac OS X.

Requirements

• Strong C programming skills.
• Past coursework or reading in the area of computer security.

Capsicum application adaptation and core libraries (GSoC)

Suggested Summer of Code 2011 project idea

Technical Contact: rwatson@, benl@

Capsicum is a new sandboxing mechanism designed for FreeBSD based on the capability security model. Initial Capsicum features are being merged to the FreeBSD 9.x kernel, but a lot of work remains to be done. Of particular interest is identifying applications that might use Capsicum, and factoring out support libraries providing features needed by many applications. For example, it should be easy to use DNS in a Capsicum sandbox but currently isn't; we might adapt the lightweight resolver daemon to serve Capsicum sandboxes, modify the resolver library to use it when in Capsicum, and modify libcapsicum to delegate resolver access to sandboxes where appropriate. Similar work could be done to provide certain types of file access authorisation, and perhaps even derive delegation requirements from ELF annotations.

References:

• Capsicum web page at Cambridge

Userland / Installation Tools Projects

BSD-licensed ELF Tools

Technical Contact: jkoshy@, kaiw@

Create BSD-licensed versions of ELF processing tools (e.g., ld, dbx, as and others) using the ELF(3) and GELF(3) API set. Identify overlapping functions in those tools and create a library out of the common functions. Identify parts which can be generated by tools (e.g., machine code parser generators) to support our Tier-1 and Tier-2 architectures.

References:

• The ELF Toolchain Project on SourceForge.Net

Requirements

• Knowledge of C.

BSD-licensed Text-Processing Tools

Part of Summer of Code 2010

Part of Summer of Code 2008

Technical Contact: dds@, gabor@

Both BenFiedler and GáborKövesdán worked on some parts of this idea in past SoC projects. Relevant progress has been made but there are still couple of things to accomplish.

grep: It has been committed to the base system and available as an alternative of GNU grep. The compatibility is good but the performance is quite behind GNU grep, which prevents us from using it as a default. There are also some problems of regular expressions involved.

sort: Mostly the large file handling (memory limit, tmp files on disk, etc.) is missing. It needs an efficient algorithm.

diff/diff3/sdiff: Many command-line options are supported but some features are still missing.

mdocml: An incompatibility came up between groff and mdocml because the latter does not support some legacy features and replaces them with a newer syntax.

groff/troff: Despite the efforts to use mdocml, it would also be possible to replace GNU groff with an implementation that does not come with a viral license. Additionally this implementation has support for common vector fonts and unicode. It has to be analyzed if those utilities are option-compatible or not. A port of this is already available as textproc/heirloom-doctools.

Requirements

• Knowledge of C.

Build options improvements

Technical Contact: netchild@

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.

boot.kernel.org Compatible Installation Image

boot.kernel.org is a project to provide boot images that can be booted over http with a small boot program (gpxe). A number of Linux distributions have installation media available. It would be useful if FreeBSD's release process could generate appropriate boot images.

Requirements

• Ability to work with Makefiles.

• Test infrastructure.

KDE front-ends to the freebsd-update(8)utility

Part of Summer of Code 2007

Technical Contact: cperciva@

The freebsd-update(8) utility is used to fetch, install, and rollback binary updates to the FreeBSD base system. A nice project would be to develop a graphical front-end for freebsd-update(8), using the QT toolkit. A GTK frontend was developed as part of GSoC 2007 and exists at berlios; the QT frontend could maybe share common functions/classes and design ideas.

Requirements

• Experience writing KDE applications

IPv6 User Land Cleanup

Suggested Summer of Code 2009 project idea

Technical Contact: gnn@

Many userland network utilities do not work correctly with IPv6.

• rpc.statd(8) is not IPv6 clean.
• rpc.rquotad(8) is not IPv6 clean.

This project could also include a broader survey of other network services in /usr/bin and /usr/sbin to make sure they're all IPv6 clean.

lint(1) improvements from OpenBSD

OpenBSD has some improvements to lint(1) which may be beneficial to have.

Requirements

• Good knowledge of C.

Libprocstat and libnetstat

Part of Summer of Code 2009

Technical Contact: rwatson@, pgj@

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.

For progress made on this sub-project so far, see its page on the wiki.

Requirements

• Good knowledge of C.

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.

Port prebind from OpenBSD

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.

Requirements

• Good C knowledge (reading and writing).

Proxy auto-config file support for libfetch

A proxy auto-config (PAC) file contains a JavaScript function "FindProxyForURL(url, host)" that determines which HTTP or SOCKS proxy, if any, to use to access a given URL. In most application the file may be specified manually or discovered using the Web Proxy Autodiscovery Protocol. Support for PAC files in libfetch would make fetch more versitle.

Supporting PAC files nominally requires a fairly complete JavaScript implementation. There appear to be no BSD Licensed JavaScript implementations so one will likely need to be written. A minimalist implementation of the language with commonly used constructs such as if/else, string comparison, and functions would be sufficient in many cases.

References:

• Wikipedia Article on Proxy auto-config

• Proxy Auto-Config File Format

Requirements

• Strong knowledge of secure C programming.

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.

m@ is working on a bundled PXE installer as part of his BSDInstaller project within 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

• Good PXE knowledge.

Regression testing system

Technical Contact: netchild@, nik@

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

Porting LTP might also be a good idea.

Requirements

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

Sysinstall

• 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 and keyboard.

Requirements

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

Tar output mode for installworld

Technical Contact: cperciva@, kientzle@

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.

Bsdtar now (8-current, 20080101) has a feature that allows it to create a tar archive from a description provided in the form of an mtree file. This description can specify owner, permissions, and contents for each entry and does not require the files on disk to already have correct ownership. This should make it possible to build a FreeBSD distribution as a non-root user. Talk to Tim Kientzle for details of the new bsdtar features and look at NetBSD, which has a similar facility, for ideas about how to proceed.

Requirements

• No fear regarding our installation system.

Unicode support in vi

Suggested Summer of Code 2011 project idea

Technical info:: on J.R. Oldroyd's Unicode Support on FreeBSD page

Many base system utilities grew multibyte support in 2004. It would be nice to continue this trend by teaching vi(1) to display and edit documents in UTF-8 encoding. The above referenced page contains info of what is needed to improve the Unicode support in vi(1).

Requirements

• Knowledge of C.

Improve cron(8) and atrun(8)

Currently, cron(8) and atrun(8) are outdated in their implementation. Here are some directions for improvement:

• Update cron(8) to ISC cron with security fixes from OpenBSD.
• Integrate the atrun(8) functionality into cron(8), as it was done in NetBSD.

Requirements

• Strong knowledge of the C language and Unix API.

Improve Wine support in FreeBSD

Suggested Summer of Code 2009 project idea

Technical Contact: kris@pcbsd.com

This last summer Tijl Coosemans did excellent work getting wine to a very usable point on FreeBSD. However, there are some issues which still need to be addressed at Wine. This would be a big improvement for our desktop users.

BSNMP enhancements (GSoC)

Suggested Summer of Code project idea

Technical Contact: syrinx@, bz@

BSNMP is a portable SNMP framework consisting of a daemon, modules and tools. It includes libraries that ease the development of loadable modules for configuring and monitoring various subsystems. You can find more information about Bsnmp. Some project ideas, but not limited to that list, can be found at BsnmpTODO.

Requirements

• Knowledge of C.
• Some familiarity with SNMP/MIBs desirable.

Port TrueCrypt as a geom_gate userland disk device implementation (GSoC)

Suggested Summer of Code project idea

Technical contact : ivoras@

TrueCrypt is a popular cross-platform on-the-fly disk encryption software. Recently tcplay, a BSD licensed option, has been developed. It should be straightforward to port it as a geom_gate device in userland.

Requirements

• Knowledge of C
• Familiarity of how disks and file systems work

Userspace pthread mutex lock contention profiling and lock order verification tool (GSoC)

Suggested Summer of Code project idea

Technical Contact: jeff@

This task would create an extension to the threading library that would allow application developers to measure and locate lock ordering and lock contention problems within their application. Such a tool is invaluable in debugging application deadlocks and creating high-performance multithreaded software. Existing lock ordering and profiling tools exist in the FreeBSD kernel, and could be used as the model for the userspace implementation. We would recommend beginning with profiling due to its immediate usefulness in optimizing performance, and to allow improvements in kernel scheduling to better manage user application lock contention.

Requirements

• Strong knowledge of C.
• Threading experience.
• Strong debugging skills.

FreeBSD port of NetworkManager

Suggested Summer of Code 2009 project idea

Technical Contact: marcus@

This task is to port NetworkManager to FreeBSD. Porting NetworkManager will also require some core userland changes to FreeBSD, especially to ifconfig.

Requirements

• C programming skills
• Knowledge of the FreeBSD net80211 wireless stack

Fix FreeBSD support in GNOME's system-tools-backends

Suggested Summer of Code 2009 project idea

Contact Info

Technical Contact: marcus@

This task is to fix FreeBSD support in sysutils/system-tools-backends.

Requirements

• Perl programming skills
• Knowledge of the FreeBSD system configuration

Extend hal support on FreeBSD

Suggested Summer of Code 2009 project idea

Technical Contact: marcus@

This task is to add hal support for some additional subsystems. In particular FreeBSD is lacking support for the ieee1394 (i.e. Firewire), bluetooth, and printer. Adding support for these subsystems will require changes to the FreeBSD kernel. Those interested should use the latest HAL Specification as a guide.

Requirements

• C programming skills
• Knowledge of the FreeBSD system internals

Finish support for compilation of i386 binaries on amd64

Suggested Summer of Code 2009 project idea

Technical Contact: kib@

The FreeBSD binutils and gcc on amd64 are capable to build 32bit binaries. What we miss is the proper includes for i386 accessed when #include <machine/some.h> is used, for the -m32 invocation of the cc. Project would provide an installation of both amd64 and i386 includes in non-conflicting way, and changes to the gcc to select proper location for machine/ based on the compilation target architecture.

Requirements

• C and shell programming skills
• Knowledge of the FreeBSD build and installation infrastructure
• Some knowledge of the gcc internals

EPUB Support in Documentation Build Infrastructure

Suggested Summer of Code 2011 project idea

Enhance the FreeBSD Documentation Project build infrastructure to generate EPUB format output suitable for eBook readers from such as iPads and Kindles.

Requirements

• Ability to work with Makefiles
• Knowledge of SGML/XML transforms

Improve webcamd support under FreeBSD 8/9+ (GSoC)

Suggested Summer of Code 2011 project idea

Technical Contact: hselasky@

Enhance the Webcamd Project. Update drivers to latest version available in the Linux kernel. Improve build system. Perform testing.

Requirements

• Good knowledge about the C programming language.
• Knowledge about V4L, DVB drivers and the Linux kernel in general.
• Knowledge about the Linux kernel build system and Makefiles.

libpw

Technical Contact:

Create a library to be able to manage users/groups easily, it also should have a pam/nss-like plugin framework for different account system.

libutil has pw_* and gr_* undocumented functions which allow user/group manipulation

writing pw_*() and gr_*() manpages

known users for that library: pkgng, pw(8)

Requirements

• Knowledge of C
• Knowledge of pam/nss

Safe crash dumps

Technical Contact:

Crash dumps are important for collecting debugging information but are also disabled by default because they can consume much space in /var if the user doesn't pay attention to them.

What we miss is a safe way to enable crash dumps by default without having to worry about them filling up /var.

Requirements

• Knowledge of C
• Knowledge of the FreeBSD system internals

Other Projects

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:

• File systems: scottl@, alfred@

• GEOM: pjd@, phk@.

• Networking: alfred@, brooks@, rwatson@, sam@

• 802.11 wireless networking: adrian@, sam@, bschmidt@

• Release Engineering / Integration: re@

• TrustedBSD / Security: rwatson@

Additionally, there are a lot of interesting mailing lists that can be used when searching information about specific subjects.

For porting ideas go to WantedPorts and for Beginner tasks check out JuniorJobs