diff --git a/en/projects/ideas/ideas.xml b/en/projects/ideas/ideas.xml index 5b02d24894..d53549864f 100644 --- a/en/projects/ideas/ideas.xml +++ b/en/projects/ideas/ideas.xml @@ -1,2067 +1,2070 @@ - $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.54 2008/03/18 13:17:26 rwatson Exp $ + $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.55 2008/03/18 17:44:47 rwatson Exp $ Embedded Reduced FreeBSD for Embedded

Technical Contact: Warner Losh

In the Linux world, there are a number of packages available which will grab a bunch of software, including Linux, the tool chains, packages, etc and create a firmware image for popular devices. Since FreeBSD is an integrated system, many of these elements are present in the base system or the ports tree.

There have been attempts at this problem over the years: nanobsd, picobsd, and tinybsd are in the tree, Sam Leffler has his own custom scripts, etc. This project would pick an approach and use the existing scripts to make it simple to create images that could be loaded into the firmware of these devices. Many of the newer devices have 8MB or 16MB flash parts, so that would be a good size to target for the kernel and ram disk image. A good way to think of this project is openwrt for FreeBSD images.

Requirements:

  • Strong C and scripting language programming skills.
  • No fear of the FreeBSD build process.
  • Good knowledge of how FreeBSD is put together.
  • Knowledge of the ports system.
 NAND Flash driver support

Technical Contact: Warner Losh

Add support for nand flash support.

Requirements:

  • Good C programming skills
  • Ability to understand FreeBSD subsystems like geom, device, etc.
 Make creating a bus easier

Technical Contact: Warner Losh

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

Technical Contact: Warner Losh

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

Technical Contact: Warner Losh

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

Technical Contact: Warner Losh

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

Technical Contact: Warner Losh

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 FAT (msdosfs) infrastructure work

Technical Contact: Robert Watson

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).
  • Make msdosfs robust in the presence of unexpected disk removal, since it is frequently used with removable devices.

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

Requirements:

  • Strong C programming skills.
  • Familiarity with concurrent programming techniques.
  • Familiarity with FAT file system layout.
  • Familiarity with virtual file system and virtual memory.
 Improve the performance of dump/restore

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

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 the current approach (an in-memory directory cache) is 90% effective when hit, it is only applicable to 25% of name lookups. On-disk indexing would improve this situation.

Requirements:

  • Knowledge of C programming.
  • Basic understanding of filesystems.
  • The book Design and Implementation of the FreeBSD Operating System.
 Analyze NetBSD's ext2fs regarding valuable improvements

FreeBSD has an implementation of the ext2fs filesystems but it contains some files under the GPL which make it undesirable, among other things, to use it in the GENERIC kernel. Ext2fs is a rather simple but practical filesystem and NetBSD has had for a while an implementation based on UFS1 sources. The NetBSD implementation needs to be analyzed regarding features and performance. If it is on par or better with our GPLed implementation, it should be ported to FreeBSD.

Requirements:

  • Knowledge of C programming.
  • Basic understanding of filesystems.
 Implement co-location for UFS2

While FreeBSD's FFS implementation is pretty much state-of-the-art, in addition to softupdates, Greg Granger proposed other strategies that would be useful, especially when working with small files. Quoting Greg Ganger: "The key insight for why current file systems perform poorly is that locality is insufficient - exploiting disk bandwidth for small data objects requires that they be placed adjacently". Explicit grouping, in particular, seems to provide important performance improvements without less implementation complexity than embedded inodes. As this changes the on-disk structure, care needs to be taken that the implementation is backwards compatible.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge of the UFS2 filesystem.
 MDFS lockups

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

Technical contact: Kris Kennaway

Take a filesystem and MPSAFE it. e.g. ext2fs, ntfs, coda, etc.

 Kernel DDB/gdb scripting

Technical contact: Kris Kennaway

The goal would be to develop scripts that automatically run a standard suite of useful debugging commands in DDB upon panic and save in a textdump. Might be too short on its own, so could be combined with a project to write gdb macro equivalents of the DDB command set, extending the macros John Baldwin has. New DDB commands and macros could also be implemented, e.g. for inspecting other common data structures.

 FIFO optimizations

Technical contact: Kris Kennaway

Evaluate the possibility of merging the FIFO implementation with the pipe implementation for improved performance. Care would need to be taken to avoid regressions, so part of this project should be attention to previous and existing FIFO bug reports, and writing of conformance testing to verify correct behaviour. Possible extensions might include a re-evaluation of some of the performance tradeoffs made in the pipe code in light of modern CPUs.

 PMC support for modern CPUs

Technical contact: Josef Koshy

Part of this project would be to add support to PMC for running on modern x86 CPUs. This is a relatively self-contained project but requires a bit of immersion in the code and the CPU manuals.

 Timecounter Performance Improvements

Technical contact: Kris Kennaway

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

Technical contact: Xin LI, Howard SU

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 has 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

Technical contact: Kris Kennaway

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.

Requirements:

  • Strong knowledge of C.
  • Understanding of kernel VM.
 Document all sysctls

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

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, ...).
  • A wiki page documenting everything related to the sound subsystem in FreeBSD has been created.

Requirements:

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

Technical contact: John Birrell

URL: Perforce repository, DTrace for FreeBSD

DTrace is a dynamic tracing facility designed by Sun Microsystems and released in Solaris 10. They have since released the major part of Solaris under the banner of OpenSolaris and the Common Development and Distribution License (CDDL) 1.0. John Birrell has created an initial port and should be contacted for information on what tasks remain to be done.

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

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.
 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.
 Kernel support for linux device drivers

Technical contact: Luigi Rizzo

Recently, a project was started to compile linux device drivers on FreeBSD 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 goal of this project is to extend this emulation layer to cover more of the linux kernel API. Two areas that need further work are the API used by network/communication device drivers (e.g. many USB wired and wireless device drivers; telephony cards), and the API used by memory-mapped devices and drivers (e.g. analog or DVB video acquisition cards, both USB and PCI).

A Summer of Code applicant would be required to choose a significant set of extensions to the existing work (e.g. one of those indicated above), and select at least two linux device drivers to be ported to FreeBSD using the newly implemented functions.

Before the start of the project a Summer of Code applicant is expected to have studied the above URL and understood the emulation technique used, and to have/acquire access to at least some of the hardware involved, so that actual functionality tests can be performed in addition to the compile tests.

 Extend ktrace/kdump 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. Some work has been completed and committed, but a few parts still remains. More information is available here.

Also, a related project would be to modify ktrace to write to pipes. Currently the ktrace infrastructure requires the dump output go to a file. It would be useful to be able to instead have it write to pipe, or in fact any type of file descriptor.

Requirements:

  • Knowledge of C.
  • Good knowledge of POSIX interfaces or how to use man(1).
  • No fear to look into the kernel sources.
 Fast syscall support for FreeBSD/i386

Technical contact: Attilio Rao, Jeff Roberson

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. David Xu has some work in progress 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.
 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.
 Implement and profile 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).
 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.

 Improving the USB stack in FreeBSD

Technical contact: Luigi Rizzo

The USB stack in FreeBSD suffers from a few problems, including lack of functionality (e.g. isochronous support for USB2 devices), lack of documentation (most of the code is undocumented and derives from other BSD implementations), lack of support (there is not, to our knowledge, active development of the stack), and the fact that it is still running under the Giant lock.

There is an alternate USB stack under development but it also suffers from its own share of problems: while it supports isochronous transfers for USB2 and does not run under Giant, it is also almost completely undocumented, and it exports a different API from the current one, which in turn causes portability problems for device drivers that run on top of USB. Additionally, it is not in widespread use.

The goal of this project is to improve the FreeBSD stack in one of the following ways:

  • Add documentation and isochronous USB2 transfers to the existing driver. Documentation also includes a detailed description of the locking requirements to ease the move to a different locking architecture;
  • Add documentation and a compatibility layer to the 'new' usb stack, and verify that the basic functionality is preserved for widely used drivers (umass, mouse, keyboard, etc.). This work will likely require some debugging of the new code which we expect to be less tested than the existing one, and so more prone to undetected bugs.

The production of suitable documentation in the source is a key requirement of the project.

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

Technical contact: Emiliano Mennucci

References: The Pluggable Disk Schedulers SoC project, Patches

Our "Pluggable Disk Schedulers" SoC 2005 project resulted in code which solved the problem where large sequential I/O requests, or certain access patterns from one or a few processes, might almost completely starve other processes. It is available as a patch for RELENG_4 and RELENG_5. Unfortunately the code in FreeBSD-current (and RELENG_6) changed too much, so that the patches can not be committed. The goal of this project is to port the pluggable disk schedulers to the GEOM framework.

Interested people should also have a look at a mail thread about this (Ulf is not working on this) and further discussion of the corresponding GEOM aspects.

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

Someone needs to finish the support for PT_SYSCALL in the ptrace() subsystem and remove the need for procfs in gcore. Removing the procfs(5) dependency from ps -e is also desirable.

Requirements:

  • C knowledge.
  • Understanding of kernel debugging interfaces.
 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.
 Sync FreeBSD i386 boot code with DragonFly

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 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.
 Syscons modularization

Separate the syscons code into distinct parts for input, output, console handling (switching, screen savers etc.) and terminal emulation. Introduce fine-grained locking. Also implement vt100 and vt220 emulation to supplement the existing SCO emulation. Add a gettytab(5) capability for specifying the terminal emulation, and add entries to /etc/gettytab for the alternative emulations.

Optionally implement xterm emulation. The top line of the screen should serve as a title bar, displaying the title set with the \e]0; escape sequence as well as the vty number.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of text terminals and terminal emulation.
 Make optional kernel subsystems register themselves via sysctl

Technical contact: Kris Kennaway

Currently there is no way for e.g., a port makefile to tell whether things like FreeBSD 5.x compatibility are present on the system (just installing the compat5x port is not enough, you need a kernel built with COMPAT_FREEBSD5). All such optional kernel features need to register themselves with the FEATURE macro so that the userland can easily query whether a given feature is present. So far not all kernel features are using this infrastructure.

There needs also to be a way to spoof those values, e.g., when the ports build cluster is building for older FreeBSD versions in a jail. Suport for this is not available in the FEATURE macro.

Requirements:

  • Good knowledge of C.
  • Kernel awareness.
 Networking csup improvements

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. Some parts of this has already been implemented, such as an RCS parser and an interface to edit RCS files. The remaining parts for this feature is RCS correctness testing, protocol correctness testing, fixing bugs and checking for memory leaks and performance issues.

Requirements:

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

Technical contact: Max Laier

Teach pf to talk to the netgraph subsystem. Requires a design on how to express this in pf.conf and implementation. Being able to use divert sockets would be interesting as well and should be largely parallel with regards to the design.

Requirements:

  • Good knowledge of C.
  • Good understanding of kernel level networking.
  • Basic understanding of pf and netgraph as a user at least.
 Magic tunnel daemon

Technical contact: Poul-Henning Kamp, Matus Harvan
WIP: http://wiki.freebsd.org/mtund

IP can be tunnelled 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.
 TCP/IP regression test suite

Technical contact: Robert Watson, George V. Neville-Neil

Design and implement a wire level regression test suite to exercise various states in the TCP/IP protocol suite. Ideally with both IPv4 and IPv6 support.

Requirements:

  • Strong TCP/IP knowledge.
 Passive libpcap based TCP session anomaly detector

Technical contact: Andre Opperman.

Listens on an interface and tracks all TCP sessions it sees. In the normal case only general information is carried forward (seq#/ack#, negotiated SYN/ACK features, etc). Whenever an anomaly happens - that is a duplicate ACK, SACK response, out-of-order segment, retransmission or others; it captures those packets into a tcpdump file for later deep inspection with Wireshark or other tools. This tool is to be deployed on live hosts and passive monitors to collect reliable condensed data about real-world behavior of TCP on the global Internet. Currently no such quantitative data exist and contribution of such a tool that can be easily run is a significant step in helping further development of TCP algorithms.

Difficulty: Medium, good familiarity with the TCP RFCs is necessary and detection of many edge cases has to be implemented correctly.

 Update wi

Technical contact: Sam Leffler

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 of undocumented parts of the kernel.
  • One wi(4) card and one other wireless device to test against.
 WPA2 preauthentication 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.
 802.11 Fuzzing and Testing

Technical contact: Sam Leffler

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 I'm not aware of any good ones that work with 802.11 + 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.)

 Ports Add hashed .db support to pkg_tools

Technical contact: Kris Kennaway

pkg_create(1) and friends use flat databases (aka ordinary files and directories in /var/db/pkg) to maintain their data. This makes it cumbersome and/or impossible to do efficient lookups of data on installed packages and makes certain operations very slow. portupgrade has the right idea of hashing this into a berkeley db file, but it uses tools that are not in the base system (ruby).

A self-contained project would be to add similar (preferably compatible) code into pkg_tools directly, possibly also extending the data that is stored and allowing for more flexible querying with tools like pkg_info (e.g. replicating the pkg_which utility of portupgrade). Adding mutual exclusion to protect concurrent pkg_add/delete operations from corrupting database state is also important.

Requirements:

  • Knowledge of C.
  • Basic understanding of the use of berkeley db.
 Cleanup of USE and WITH variables

Technical contact: Erwin Lansing

Make these more consistent. WITH_* should be user-settable variables while USE_* only is for internal use in the ports.

Requirement:

  • Strong knowledge of shell and make code.
  • A basic understanding of the inner workings of the ports tree.
 Collect the pkg-message output

Technical contact: Pav Lucistnik

Collect the pkg-message output of dependencies and print them together after the whole build finishes.

Details: Change the current ad-hoc way of including pkg-message in the stdout of the build process. Automatically display pkg-message in post-install, if present. For the dependencies, save the copies of pkg-messages, as displayed in post-install, in /var/db/pkg, and display them collectively once the whole build finishes. Also allow for manual review by user later (new flag to pkg_info(1)).

Requirements:

  • Knowledge of shell and make coding, and basic overview of how ports works.
  • Basic knowledge of C.
 COMPAT_43TTY

Technical contact: Ed Schouten

Some ports may break when removing COMPAT_43TTY from the kernel configuration since they assume old ioctl's when they identify FreeBSD. The goal of this entry is to:

  • Identify the ports which behave like this. A tinderbox setup is probably needed. Using grep to find "#include <sgtty.h>" and this list from Kris Kennaway might also be good starting points.
  • Fix breakages and send patches upstream.

Note: Ed is working on this. Please coordinate with him.

Requirements:

  • Knowledge of autotools.
  • Time and patience.
 Improvements of OPTIONS

The current OPTIONS infrastructure can be improved in several ways.

  • It should be possible to define OPTIONS after bsd.ports.pre.mk.
  • Add an API to override the current curses based interface with a different GUI, e.g. zenity/gdialog instead of dialog.
  • More room for a description in the OPTIONS dialog - possibly some sort of help dialog could be provided for each option, like in sysinstall.
  • Better handling of cases where OPTIONS are changed/added/removed between upgrades.
  • The ability to depend on, or at least test, OPTIONS set in other ports. Possibly it would be nice to enforce setting variables that are depended upon when the port is being installed as a dependency.
  • Other types of OPTIONS controls - A text box in particular would be useful for entering variables that need real values.
  • The possibility for mutually exclusive OPTIONS.
  • Bugfixes:
    • If you attempt to run make config for a port with ${PKGNAMEPREFIX} defined, the make config process will error out with:
      ===> Using wrong configuration file /path/options/file
      The solution is to define LATEST_LINK to be prefix-${PORTNAME}, but this should be done internally.

Requirements:

  • Strong knowledge of shell and make code.
  • A basic understanding of the inner workings of the ports tree.
 Package tools improvements

The pkg_* tools, which deal with the installation of pre-build binary package of ports, could do with a code cleanup or maybe even a rewrite from scratch. Some features of the ports tree are not supported by the pkg_* tools, e.g. versioned dependencies.

Requirements:

  • Strong knowledge of C code.
  • A basic understanding of the inner workings of the ports tree.
 Parallelization in the Ports Collection

Technical contact: Pav Lucistnik

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.
 Utility for safe updating of ports in base system

Also known as rewrite portupgrade in C.

Write a new utility for the pkg_install suite, possibly named pkg_upgrade(1), implementing a subset of existing portupgrade functionality. The required functionality is:

  • fixing @pkgdep records in +CONTENTS file
  • fixing +REQUIRED_BY records
  • storing old copies of shared libraries after shmajor number change in /usr/local/lib/compat/pkg
  • upwards and downwards recursive modes

Anything that existing portupgrade can do is a desired functionality. It would be nice to be command line compatible with portupgrade, but it's not a requirement.

Requirements:

  • Basic understanding of the Ports Collection design.
  • Good skills writing C code.
  • Ability to read Ruby will help.
 Security Audit kernel event sources

Technical contact: Robert Watson

A number of kernel security subsystems, such as IPFW and pf, generate security log data. This task involves identifying potential sources of security event information in the kernel and modifying kernel subsystems to log that information using the kernel security event auditing system. User and programmer documentation of audit may be found on the TrustedBSD Documentation Page. There are also extensive manual pages relating to audit in FreeBSD. This project will require careful security analysis and kernel programming, and will likely need some re-working of the kernel audit framework (which is currently entirely focused on gathering user and kernel system call audit data).

Requirements:

  • Strong C programming skills.
  • Familiarity with concurrent programming techniques.
  • General understanding of TCP/IP firewalls.
  • Willingness to read the CC/CAPP specification.
 Distributed audit / log shipping daemon

Technical contact: Robert Watson
WIP: http://wiki.freebsd.org/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.
 Libfetch authentication support

Technical contact: Poul-Henning Kamp

Currently libfetch only supports basic HTTP authentication, which is generally frowned upon because it transmits the username and password on the wire (base64 encoded). Add RFC2617 digest authentication.

 Mandatory Access Control

Technical contact: Robert Watson

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.
 Security regression tests

Technical contact: Robert Watson

FreeBSD is undergoing constant and active improvement to all of its critical subsystems, from file systems to the network stack. With any change, there is a risk of introducing bugs or regressions. The goal of this task is to produce a security regression test suite, which encapsulates requirements regarding system security properties and tests that they (still) hold. Areas to test include file system access control, privilege, authentication, cryptography, process containment, and more. There are some current tests along these lines in the FreeBSD regression test tree, but they are both incomplete and and inadequate. New tests must be created; existing tests must be completed and updated.

Requirements:

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

Technical contact: Robert Watson, Dawidek

The NFSv4 RFC and follow-on drafts specify a new Access Control List (ACL) format loosely based on NTFS ACLs. This format is not directly compatible with existing POSIX.1e ACLs, but has been adopted by a number of recent UNIX file systems (including Apple's HFS+ and Sun's ZFS file systems) in order to improve Windows compatibility. This project is multi-part:

  • research current specifications and implementations of NFSv4 ACLs,
  • implement an ACL library in userspace,
  • port the ACL implementation to the kernel and enhance the kernel ACL infrastructure to support NFSv4 ACLs,
  • implement optional NFSv4 ACL support on UFS2 and ZFS,
  • investigate NFSv4 ACL support for Samba and smbfs,
  • implement a test suite exercising relevant aspects of NFSv4 ACL implementation, both basic rule evaluation and its integration with the nominally incompatible UNIX owner, group, and mode.

Requirements:

  • Strong C programming skills.
  • Tolerance for IETF specifications.
  • Appreciation for the nasty subtleties of access control.
  • Rigorous and devious mindset.
 Audit and Jail

Technical contact: Robert Watson, Christian Peron

The TrustedBSD Audit implementation allows fine-grained monitoring of processes in a FreeBSD install. This task extends the Audit - implementation to have specific support for Jails: it teaches the - audit kernel code how to handle the security properties of jails, - implements independent audit configurations and a trail for each - jail (possibly in addition to a global jail), and tags audit - records with BSM zone tags to indicate which jail they came from. - It also includes writing a test suite to confirm that it all works - properly.

- + implementation to have specific support for Jails:

+
    +
  • teach the audit kernel code how to handle the security + properties of jails,
    • +
  • implements independent audit configurations and a trail for + each jail (possibly in addition to a global jail),
    • +
  • tags audit records with BSM zone tags to indicate which jail + they came from,
    • +
  • write a test suite to confirm that it all works properly.
    • +

Requirements:

  • Strong C programming skills.
 Userland / Installation Tools BSD-licensed ELF Tools

Technical contact: Joseph Koshy

Create BSD-licensed versions of ELF processing tools (e.g., ld, dbx, as and others) using the ELF(3) and GELF(3) API set in FreeBSD -CURRENT. 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.

Requirements:

  • Knowledge of C.
 BSD-licensed Text-Processing Tools

Technical contact: Diomidis Spinellis

Create/port BSD-licensed versions of one or more of the text processing tools that are currently missing from the FreeBSD distribution: sort, diff, and the grep family. Licensed versions of some or all of these tools are already included in OpenBSD, so this task involves more porting and feature completion than development from scratch. Emphasis should be placed on performance, standards-compliance, and support for handling wide character sets.

Requirements:

  • Knowledge of C.
 Build options improvements

Technical contact: Alexander Leidinger, Gardner Bell

The new "delete-old" and "delete-old-libs" target in /usr/src for 6.1 and -CURRENT should be extended to support the WITHOUT_* knobs, e.g. WITHOUT_RESCUE or WITHOUT_CRYPT, and delete files which are covered by those knobs. Some switches have already been covered. You can view a list of all switches and what effect they have here.

Requirements:

  • Time to build and install the world several times.
  • A way to determine which files were not touched by an installworld.
 KDE front-ends to the freebsd-update(8)utility

Technical contact: Colin Percival

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

Technical contact: George V. Neville-Neil

Many userland network utilities do not work correctly with IPv6.

  • rpc.statd(8) is not IPv6 clean.
  • rpc.rquotad(8) is not IPv6 clean.
  • who(1) truncates IPv6 addresses in its output.

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

Technical contact: Robert Watson

Create, similar to libmemstat, wrapper libraries to support monitoring and management applications to avoid direct use of kvm. Three parts to the project: for each of the above, add kernel support to export data in a less ABI-sensitive way using sysctl, write a library to present the information in an extensible way to applications, and update applications to use the library instead of reaching directly into kernel memory / consuming sysctls. The goal is to allow the kernel implementation to change without breaking applications and requiring them to be recompiled, and to allow monitoring functions to be extended without breaking applications. This should also facilitate writing new classes of monitoring and profiling tools.

Requirements:

  • Good knowledge of C.
 Multibyte collation support

Technical Contact: Diomidis Spinellis

Currently FreeBSD supports only single byte collation. Multibyte collation support would be nice. This might involve implementing the Unicode Collation Algorithm (see http://unicode.org/reports/tr10/), writing a tool to compile the Default Unicode Collation Element Table (http://www.unicode.org/Public/UCA/latest) into an efficient lookup format, and integrating the corresponding conformance tests (http://www.unicode.org/Public/UCA/latest/CollationTest.html) into the FreeBSD regression testing framework.

Benefits:

  • Proper national sorting in UTF-8 and other multibyte locales.

Requirements:

  • Knowledge of C.
  • Familiarity with locale subsystem and relevant ISO standards.
 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.
 Performance tracking

Technical contact: Brooks Davis
WIP: Erik Cederstrand

The "performance tracking" entry is meant to monitor the performance of FreeBSD itself over the development time, e.g. someone makes a change to the kernel and the tracking system is able to show the performance impact to various subsystems (microbenchmarks) or to real world applications like apache or mysql (macrobenchmarks). The tracking system should be able to do this with multiple machines and multiple configurations (while the goal is not to compare configurations or machines (but different FreeBSD versions) we would not mind if it is also able to do this. This does not need to be implemented from scratch, it is allowed/encouraged to reuse existing free software.

Requirements:

  • Access to multiple machines.
 Port libumem to FreeBSD

Solaris 9 and later versions include libumem, a user space slab allocator that includes debugging features we may want to have on FreeBSD too.

Yen-Ming Lee has a port of the Linux port. He is looking for someone who is interested in benchmarking, testing, or evaluating his port. It is available in ports/devel/umem.

Jason Evans has a benchmark suite at here. A description of the benchmark can be found in his jemalloc paper

Online references for libumem are (in suggested reading order):

Requirements:

  • Good C knowledge (reading and writing).
  • Experience with debugging allocation problems.
 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:

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.

Markus Boelter 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: Alexander Leidinger, Nik Clayton

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.
 Schedgraph Improvements

Technical contact: Jeff Roberson

Schedgraph is a tool for analyzing scheduling events and visually displaying them in such a way that they reveal interesting kernel and application performance problems. It is written in python/tkinter and interfaces with the kernel via the generic KTR kernel tracing system. Schedgraph is in need of many features and general improvements such as the ability to synchronize timestamps in SMP systems, plotting time spent spinning on spinlocks, improved visual appearance, faster graphing time, and many other features. Access to an 8 processor FreeBSD machine will be provided to implement advanced SMP features.

Requirements:

  • Working understanding of python.
  • Some familiarity with any widget set recommended.
  • Ability to recompile and reconfigure a FreeBSD kernel.
 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: Colin Percival, Tim 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

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)

Technical contact: Yar Tikhiy

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

  • Convert atrun(8) to using setusercontext(3) instead of creating the job context through a sequence of basic syscalls.
  • Ultimately, the atrun(8) functionality could be integrated into cron(8), as it has already been done in NetBSD.

Requirements:

  • Strong knowledge of C.
  • Understanding of PAM API.
 Improve Wine support in FreeBSD

Technical contact: Kris Moore

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 http://wiki.freebsd.org/Wine. This would be a big improvement for our desktop users.