diff --git a/en/projects/ideas/ideas.xml b/en/projects/ideas/ideas.xml index 0e208b6c77..b76d8cd7c5 100644 --- a/en/projects/ideas/ideas.xml +++ b/en/projects/ideas/ideas.xml @@ -1,1795 +1,1764 @@ - $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.23 2007/05/01 08:36:50 netchild Exp $ + $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.24 2007/05/01 18:08:41 netchild Exp $ 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.
 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.
 - - TMPFS - - -

Technical contacts: Alexander Leidinger, - Howard SU, - Glen Leeder

-

At the moment FreeBSD includes a memory-based file system called mfs. - mfs is just an implementation of the regular ffs - designed for - persistent storage - on top of the (volatile) virtual memory system. - This means that it uses the same data structures as the on-disk - implementation, rendering less than optimal performance and memory - usage. With tmpfs, FreeBSD would gain a memory file system which uses - less memory and is faster.

-

Goals:

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

Howard and Glen are working on this, the current status is available - in the wiki.

-

Requirements:

-
    -
  • Ability to read and understand foreign C code.
    • -
  • Ability to write C code.
    • -
  • A little bit of knowledge of the VFS subsystem.
    • -
- - - Kernel 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)

Another part 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.
 CPU usage display in top

The current kernel statistics do not know how to calculate the CPU usage of threaded processes. A volunteer has to understand the current statistics model, design a new statistics model and implement it. This problem only occurs with M:N threading on libpthread.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • A good understanding of the FreeBSD SMP system.
 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

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

 iSCSI

Technical contact: Danny Braniss

Danny Braniss has been working on an iSCSI stack for FreeBSD for some time now. His work is in Perforce, and he has posted several patch sets and had numerous discussions on the mailing lists.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge about (i)SCSI/CAM.
 Locking the FireWire device driver

Technical contact: Hidetoshi Shimokawa

The IEEE1394 (a.k.a. FireWire) device driver in FreeBSD is still under the Giant lock. The FireWire driver consists of several parts (fwohci, firewire, sbp, fwe and fwip) and they all need to be locked.

Goals:

  • Protect the driver by SMP locks and remove the Giant lock from the driver.

Requirements:

  • Knowledge of kernel programming.
  • Knowledge of device drivers.
  • Knowledge of SMP locking.
 New bus_alloc_resources() API

Technical contact: Warner Losh

Recently, bus_alloc_resources has been added to the kernel. This, coupled with the bus_space_{read,write} family of functions can significantly reduce the setup needed for driver resource allocation. Unfortunately, most of the drivers in the tree have not yet been converted, thus ensuring that the old, bad way continues. What is needed is for someone to go through the drivers in the tree and convert them. After conversion, they need to ensure that they still work on at least some hardware and work with someone to get them committed. Warner Losh is available for review and coordination of committing.

Requirements:

  • Ability to read, write and understand C code.
  • Knowledge about device drivers.
  • Access to hardware to test on.
 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).

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Knowledge of GEOM (or interest in getting familiar with it).
 Port OpenBSD's sensors framework

References: Overview, http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/, http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/bioctl/, http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/safte.c

The OpenBSD sensors framework is an unified way of handling any kind of hardware sensor one can image. A sensor driver collects data from system sensors, SAS devices, harddisks, ... and allows an administrator to query the data with the unified management interface.

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
 Remove procfs dependencies

Technical contact: Maxime Henrion

Someone needs to finish the support for PT_SYSCALL in the ptrace() subsystem, and add support for another ptrace() command that will replace the PIOCWAIT and PIOCSTATUS ioctls of procfs (should probably be named PT_WAIT), in order for truss(1) to be able to work without procfs(5). Removing the procfs(5) dependency from ps -e is also desirable.

Requirements:

  • C knowledge.
  • Understanding of kernel debugging interfaces.
 Rewrite the in-kernel file system syncer

References: mail #1, mail #2

Goals:

  • Change the syncer so it can sync out to multiple physical devices simultaneously.
  • Only write out up to X megabytes of data, remember where it left off, and then proceed to the next dirty file (OpenBSD and NetBSD already do this).
  • Replace the write_behind code with something (detect the existence of a large amount of sequential dirty data and kick another thread to flush it out synchronously, instead of doing it itself asynchronously) integrated into the syncer (the data set size could perhaps be increased from 64KB to 1MB).

Requirements:

  • Ability to read and understand foreign C code.
  • Ability to write C code.
  • Some understanding of the VM system / buffer cache.
 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.
 Sysenter for x86 syscalls.

Technical contact: Jeff Roberson

Sysenter is an optional feature on x86 processors that significantly reduces the cost of calling system calls. Implementing support for this feature would require run-time selection of syscall code, most likely using a page which is always mapped into each process that contains the system call code. This would also require some minor infrastructure in the kernel to provide the correct entry points and stacks for kernel entry. If there is enough time remaining other features could be added to this global shared page to improve performance of other syscalls.

Requirements:

  • Solid grasp of assembly and machine state issues.
  • Some familiarity with the FreeBSD VM.
 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. This is very useful for storing a full copy of the CVS repository on the client machine.

Requirements:

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

Technical contact: Robert Watson

Implementing HTTP support for pxeboot would allow us to boot a machine using PXE and pull down a kernel from a web server rather than NFS. This will allow us to install from DHCPD + Apache or even just DHCPD + a remote web server. As PXE does not provide an integrated TCP stack, at least a minimal TCP implementation would need to be present in the FreeBSD PXE loader.

Requirements:

  • Good PXE knowledge.
  • Detailed knowledge of TCP/IP.
 NFS Lockd (improve semantics)

Technical contact: Alfred Perlstein

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

Requirements:

  • Good knowledge of C.
 NFS Lockd (kernel implementation)

Technical contact: Alfred Perlstein

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

Requirements:

  • Good knowledge of C.
  • Good understanding of NFS.
  • Good understanding of locking.
  • Good understanding of RPC.
  • Good understanding of kernel level networking.
 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.
 Super tunnel daemon

Technical contact: Poul-Henning Kamp

IP can be tunneled over IP, UDP, TCP, SSH, DNS, HTTP and many other protocols, and this means that it is often possible to get a connection out through a firewall, but each of these encapsulations require prior setup of a specific program for each encapsulation, and the user must experiment to decide which one to use at any one time. The super tunnel daemon should implement pluggable encapsulations and make it automatically select the most efficient encapsulation that works at any one time. The user should not notice transitions from one encapsulation to another, apart from maybe a small delay.

Wanted features (not sorted or prioritized):

  • Autodetection of the environment (DHCP, DNS, routing, ...) in a non-offensive way (no global portscans allowed; asking via DHCP, zeroconf or similar technologies is ok) as far as possible.
  • Plugin architecture for easy addition of further encapsulations.
  • Failover from one encapsulation to another.
  • Distinct configuration files for encapsulations which need to be configured (e.g. proxy, authentication, ...).
  • Possibility to disable installed encapsulations.
  • Print/log hints for protocols which require some configuration, e.g. telling the user to use keys and perhaps the ssh-agent for ssh.
  • Configurable additional plugin directories (for plugins installed via the ports collection).
  • Log how it is able to tunnel the traffic (this also makes it useful for finding unwanted holes in the configuration of a firewall).

Requirements:

  • Good knowledge of C.
  • Good knowledge about networks.
 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.
 Update wi

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.
 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.
 Automatic registering of UID and GID

Some sort of mechanism for adding/removing users/groups automatically, rather than using home-brew pkg-install scripts. It would need to be a bit more sophisticated than only registering the UID/GID, to deal with setting the other passwd(5) fields; a port might need more than one user; some ports might want a specific ID, others just the next available one, etc, etc.

Perhaps ports that have UIDs registered in the handbook could also be registered in a file inside /usr/ports, which the framework would use in UID creation requests.

Requirements:

  • Strong knowledge of shell and make code.
  • A basic understanding of the inner workings of the ports tree.
 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.

And finally, unrelated to previous steps, but also desirable. Add parallelization inside single builds, ie. enable -jX flag inside vendor makefiles. This will allow us to exploit the power of multi-core systems when building single port. Because a lot of vendor code does not work correctly when built with -jX flag, some kind of whitelist or blacklist must be implemented.

Requirements:

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

Write a small C/shell app that will scan the installed ports and show all UPDATING entries that affect one of the installed ports, and are relevant on the given machine (ie. user haven't already performed the update). Possibly the UPDATING format will have to be expanded to record the versions of affected ports, like:

gettext<0.16 -> gettext>=0.16

The app will be used standalone, and called from pkg_version or portupgrade.

Requirements:

  • Basic shell/C coding.
 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 daemon

Technical contact: Robert Watson

Create a tool that manages per-machine audit records and submits them to a central site for processing and long-term archiving/management. Ideally with support for SSL (or the like) so they do not travel on the wire in the clear.

Requirements:

  • Strong (portable) C programming skills.
  • Knowledge of the audit subsystem.
 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.
 Userland / Installation Tools BSD-licensed ELF Tools

Technical contact: Joseph Koshy

Create BSD-licensed versions of ELF processing tools (e.g., ld, nm, as and others) using the ELF(3) and GELF(3) API set in FreeBSD -CURRENT.

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.
 GNOME and/or 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 at graphical front-end for freebsd-update(8), using the GTK and/or QT toolkits.

Requirements:

  • Experience writing GNOME and/or 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

Currently FreeBSD supports only single byte collation. Multibyte collation support would be nice.

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

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).
 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 visualy 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: Robert Watson, Colin Percival

Instead of installing using install, mkdir, mtree, etc, directly construct a tarball. This would allow creating install distributions without root access, as setuid etc would never hit the local disk. This would require some retrofitting of our installation mechanisms.

Requirements:

  • No fear regarding our installation system.
 Unicode support in vi

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.

Requirements:

  • Knowledge of C.