No OneTemporary
Actions

Size

79 KB

Referenced Files

None

Subscribers

None

View Options

	diff --git a/en/projects/ideas/ideas.xml b/en/projects/ideas/ideas.xml
	index ed7afdb64e..50e2e93dd3 100644
	--- a/en/projects/ideas/ideas.xml
	+++ b/en/projects/ideas/ideas.xml
	@@ -1,1967 +1,1969 @@
	<?xml version="1.0" encoding="ISO-8859-1" ?>
	<!DOCTYPE news PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
	Ideas//EN"
	"http://www.FreeBSD.org/XML/www/share/sgml/ideas.dtd">

	<!-- Simple schema for FreeBSD Project feature request ideas.

	Top level element is <ideas>, which contains a collection of
	<category>s. Each category contains a <title> element, and a
	collection of <idea> elements.

	Each <idea> contains a <title>, <desc>, and <requirements>.
	-->

	<ideas>
	<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
	<cvs:keyword name="freebsd">
	- $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.114 2009/03/15 23:27:11 sam Exp $
	+ $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.115 2009/03/16 00:27:38 brooks Exp $
	</cvs:keyword>
	</cvs:keywords>

	<category>
	<title>Embedded</title>

	<idea id="reduced-size-kernel">
	<title>Reduced FreeBSD kernel size for embedded</title>
	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

	<p>The FreeBSD kernel has been optimized over the years for a
	server or workstation environment. Memory is plentiful in these
	environments, so little attention was given to the size of the
	kernel. There's a number items in the kernel that can be made
	optional without reducing affecting the functionality needed in
	an embedded environment. These include things like not
	compiling in strings into the kernel, less agressively inlining
	code, making some non-optional features optional and investigating
	compile time flags. This task requires identifying potentially
	optional kernel content and building the infrastructure to make
	that content optional.</p>
	<p><strong>requirements</strong>:</p>
	<ul>
	<li>Strong C language programming skills.</li>
	<li>Understanding of system calls and general kernel architecture.</li>
	</ul>
	</desc>
	</idea>

	<idea id="nand-flash">
	<title>NAND Flash driver support</title>
	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
	<p>Add support for nand flash support.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C programming skills</li>
	<li>Ability to understand FreeBSD subsystems like geom, device, etc.</li>
	</ul>
	</desc>
	</idea>

	<idea id="bus-abstraction">
	<title>Make creating a bus easier</title>
	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C programming skills</li>
	<li>Good knowledge of the NewBus configuration system in FreeBSD</li>
	</ul>
	</desc>
	</idea>

	<idea id="variable-hints">
	<title>Variable hints</title>
	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C programming skills</li>
	</ul>
	</desc>
	</idea>

	<idea id="arm-cleanup">
	<title>ARM cleanup</title>
	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

	<p>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).</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C programming skills</li>
	<li>Good refactoring skills</li>
	</ul>
	</desc>
	</idea>

	<idea id="ppc-bringup">
	<title>PPC/ARM/MIPS bring up</title>

	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C programming skills</li>
	<li>Good kernel debugging skills</li>
	</ul>
	</desc>
	</idea>

	<idea id="overhaul-config">
	<title>Overhaul the config system</title>

	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:imp@FreeBSD.org">Warner Losh</a></p>

	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C programming skills</li>
	<li>Good kernel debugging skills</li>
	<li>Ability to withstand Bikesheds</li>
	</ul>
	</desc>
	</idea>

	</category>

	<category>
	<title>File System</title>

	<idea id="msdosfs" class="soc">
	<title>FAT (msdosfs) infrastructure work</title>

	<desc>
	<p><strong>Technical Contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
	<p>The FreeBSD FAT implementation, msdosfs, offers scope for a number of
	projects:</p>
	<ul>
	<li>General cleanup.</li>
	<li>Introduce appropriate locking to make the file system operate without
	the Giant lock (MPSAFE).</li>
	</ul>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>Familiarity with concurrent programming techniques.</li>
	<li>Familiarity with FAT file system layout.</li>
	<li>Familiarity with virtual file system and virtual memory.</li>
	</ul>
	</desc>
	</idea>

	- <idea id="extenddump" class="soc">
	+ <idea id="extenddump">
	<title>Improve the performance of dump/restore</title>

	<desc><p>A performance evaluation of the split cache (as is) and an unified cache
	(like e.g. NetBSD) would be interesting. More details in <a
	href="http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html">
	this</a> mail to the hackers mailing list. Additional improvements are
	welcome too.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C programming.</li>
	<li>Basic understanding of backup/restore procedures.</li>
	</ul>
	</desc>
	</idea>

	<idea id="extendufs2" class="soc2008">
	<title>Extend UFS2 with on-disk indexing</title>

	<desc><p><strong>Technical Contact</strong>: <a
	href="mailto:dwmalone@FreeBSD.org">David Malone</a></p>

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

	<idea id="portext2fs">
	<title>Analyze NetBSD's ext2fs regarding valuable improvements</title>

	<desc><p>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
	href="http://ezine.daemonnews.org/200006/ext2fs.html">a while</a>
	an <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/ufs/ext2fs/">
	implementation</a> 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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C programming.</li>
	<li>Basic understanding of filesystems.</li>
	</ul>
	</desc>
	</idea>

	<idea id="colocation">
	<title>Implement co-location for UFS2</title>

	<desc><p>While FreeBSD's FFS implementation is pretty much
	state-of-the-art, in addition to softupdates, Greg Granger <a
	href="http://www.ece.cmu.edu/~ganger/papers/cffs.html">proposed</a>
	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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>Knowledge of the UFS2 filesystem.</li>
	</ul>
	</desc>
	</idea>

	<idea id="mdfs">
	<title>MDFS lockups</title>

	<desc><p>Fix MDFS lockups when using async operation modes. <a
	href="&cgibase;/cvsweb.cgi/sys/dev/md/md.c#rev1.115">Revision 1.115 of
	md.c</a> has a discussion of the problem.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>Knowledge of the VFS and VMA subsystems.</li>
	</ul>
	</desc>
	</idea>

	<idea id="mpsafe-filesystem-work" class="soc">
	<title>MPSAFE filesystem work</title>

	<desc>
	<p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

	<p>Take a filesystem and MPSAFE it. e.g. ext2fs, ntfs, coda, etc.</p>
	</desc>
	</idea>

	</category>

	<category>
	<title>Kernel</title>

	<idea id="ddb-gdb-scripting" class="soc">
	<title>DDB/gdb scripting</title>

	<desc><p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

	<p>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.</p>
	</desc>
	</idea>

	<idea id="fifo-optimizations" class="soc">
	<title>FIFO optimizations</title>

	<desc><p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

	<p>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.</p>
	</desc>
	</idea>

	<idea id="pmc-modern-cpus" class="soc">
	<title>PMC support for modern CPUs</title>

	<desc><p><strong>Technical contact</strong>: <a href="mailto:jkoshy@FreeBSD.org">Josef Koshy</a></p>

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

	</desc>
	</idea>

	<idea id="timecounter-perf" class="soc">
	<title>Timecounter Performance Improvements</title>

	<desc>
	<p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

	<p>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.</p>
	</desc>
	</idea>

	<idea id="autoreport" class="soc">
	<title>Automated kernel crash reporting system</title>

	<desc>
	<p><strong>Technical contact</strong>: <a href="mailto:delphij@FreeBSD.org">Xin LI</a>, <a
	href="mailto:howardsu@FreeBSD.org">Howard SU</a></p>

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

	<p>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</p>

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of C.</li>
	<li>Understanding of kernel debugging.</li>
	<li>Knowledge about web application as well as database.</li>
	<li>Understanding of user privacy protection.</li>
	</ul>
	</desc>
	</idea>

	<idea id="setproctitle" class="soc2007">
	<title>Avoiding syscall overhead</title>

	<desc>
	<p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>

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

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

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of C.</li>
	<li>Understanding of kernel VM.</li>
	</ul>
	</desc>
	</idea>

	<idea id="docsysctl">
	<title>Document all sysctls</title>
	<desc>
	<p><strong>Technical contacts</strong>: <a
	href="mailto:mat@FreeBSD.org">Mathieu Arnold</a>, <a
	href="mailto:brd@FreeBSD.org">Brad Davis</a></p>
	<p>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.</p>
	<ul>
	<li>Find every undocumented sysctl in the kernel.</li>
	<li>Try to determine what this sysctl is for and document it.</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	</ul>
	</desc>
	</idea>

	<idea id="docsound">
	<title>Document the sound subsystem</title>

	<desc>
	<p><strong>Technical contacts</strong>: <a
	href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a>, <a
	href="mailto:ariff@FreeBSD.org">Ariff Abdullah</a></p>
	<ul>
	<li>Add sound subsystem related section 9 manual pages, so far no sound
	subsystem related manual pages exists.</li>
	<li>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 <a
	href="http://people.FreeBSD.org/~cg/template.c">this template.</a></li>
	<li>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, ...).</li>
	<li>A <a href="http://wiki.freebsd.org/soundsystem">wiki page</a>
	documenting everything related to the sound subsystem in FreeBSD has been
	created.</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Documentation writing skills.</li>
	</ul>

	</desc>
	</idea>

	<idea id="dtrace" class="soc">
	<title>DTrace</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:jb@FreeBSD.org">John Birrell</a></p>
	<p><strong>URL</strong>: <a
	href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/dtrace">Perforce
	repository</a>, <a
	href="http://people.freebsd.org/~jb/dtrace/index.html">DTrace for
	FreeBSD</a></p>
	<p>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;
	two possible areas of work are:</p>
	<ul>
	<li>We need a clean CTF implementation for FreeBSD to avoid the license
	(CDDL) that Sun has on their code. John will write a specification about
	the file format and the Summer of Code project is to implement that and
	write tests for the implementation without looking at the Sun code.</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>A good understanding of the FreeBSD kernel.</li>
	</ul>
	</desc>
	</idea>

	<idea id="assembler">
	<title>DWARF2 call frame information</title>

	<desc>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of assembly code.</li>
	<li>Knowledge of ".cfi_*" pseudo-ops to insert dwarf2 frame descriptors.</li>
	</ul>
	</desc>
	</idea>

	<idea id="kernel-dvb" class="soc">
	<title>Kernel support for linux DVB device drivers</title>

	<desc>
	<p><strong>Technical contact</strong>: <a href="mailto:luigi@FreeBSD.org">Luigi Rizzo</a></p>

	<p>In early 2007 we started a project was started to support the
	building of linux device drivers on FreeBSD.
	This was done through an in-kernel emulation layer, which
	implements part of the linux kernel API on top of the FreeBSD
	kernel API. The initial implementation was good enough to
	support a few USB webcam drivers, and is documented
	<a
	href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.
	The code is actually available as a port, devel/linux-kmod-compat,
	and a popular driver that uses this infrastructure is
	multimedia/linux-gspca-kmod .
	</p>
	<p>We would like to use a similar approach to add support
	for DVB devices, which are widely supported in Linux
	but not in FreeBSD. In particular we expect the project to provide,
	within the FreeBSD kernel, enough of linux compatibility to build
	the core components of the drivers/media/ linux kernel, and then
	a few device drivers including one for a PCI DVB card (e.g.
	saa7134-based).
	</p>

	<p>Before the start of the project, a Summer of Code applicant is expected to
	i) become familiar with the approach used by linux-kmod-compat;
	ii) set up a proper test environment, with a couple of DVB devices
	supported by linux, and a working linux installation so that
	one can compare results;
	iii) become familiar with the architecture of the linux code in
	drivers/media.
	<br/>
	Probably the attention should be focused in PCI devices, because
	at this stage the USB stack is in a transition phase and would
	pose some additional difficulties.
	</p>
	<p>
	Expected results are a working porting infrastructure, a working
	linux-dvb-kmod device driver, and a working application to demonstrate
	that the driver is working as expected. We suggest to look at
	"kaffeine" for which a FreeBSD port already exists.
	</p>
	</desc>
	</idea>

	<idea id="ktrace">
	<title>Extend ktrace/kdump output</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a></p>
	<p>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 <a
	href="http://lists.freebsd.org/pipermail/freebsd-arch/2006-April/005107.html">here</a>.</p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C.</li>
	<li>Good knowledge of POSIX interfaces or how to use man(1).</li>
	<li>No fear to look into the kernel sources.</li>
	</ul>
	</desc>
	</idea>

	<idea id="fastcall">
	<title>Fast syscall support for FreeBSD/i386</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:attilio@FreeBSD.org">Attilio Rao</a>, <a
	href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>
	<p>The instruction pair sysenter and sysexit can contribute to certain
	performance improvements when a syscall is made on IA32. There is however
	no implementation of this available for FreeBSD, so a volunteer
	would have to add sysenter/sysexit support to the kernel. This
	needs to be properly evaluated and benchmarked though, so a complete
	implementation should therefore also contain informative benchmarks which
	shows a clear improvement in performance. It is also important to stress
	the fact that this project is of research quality and measures should be
	taken to ensure that no regressions are introduced. Another interesting
	extension to this project would be to investigate and evaluate the
	possibility to use mmx/xmm registers to gather syscalls arguments.
	<a href="mailto:davidxu@FreeBSD.org">David Xu</a> has some <a
	href="http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064403.html">work
	in progress</a> in his <a
	href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/davidxu/sysenter">sysenter</a>
	branch in the perforce repository.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>Ability to write and understand x86 assembly.</li>
	</ul>
	</desc>
	</idea>

	<idea id="geninput" class="soc2007">
	<title>Generic input device layer</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:philip@FreeBSD.org">Philip Paeps</a></p>
	<p><strong>WIP</strong>: <a href="http://wiki.freebsd.org/GenericInputDeviceLayer">http://wiki.freebsd.org/GenericInputDeviceLayer</a></p>
	<p>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). This project was worked on as part of
	Google Summer of Code 2007, and you can find <a
	href="http://wiki.freebsd.org/GenericInputDeviceLayer">more information on
	the FreeBSD.org wiki</a></p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	</ul>
	</desc>
	</idea>

	<idea id="powerd">
	<title>Implement and profile algorithms for powerd</title>
	<desc>
	<p>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 <a href="mailto:acpi@FreeBSD.org">ACPI</a> mailing
	list and Bruno Ducrot has some early patches.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Basic C knowledge.</li>
	<li>Laptop supported by cpufreq(4).</li>
	</ul>
	</desc>
	</idea>

	<idea id="interactive-splash">
	<title>Interactive Splash Screen</title>

	<desc><p>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.</p></desc>
	</idea>

	<idea id="pcihotplug">
	<title>PCI-Hotplug support</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:bms@FreeBSD.org">Bruce M. Simpson</a></p>
	<p><!-- Description needed --></p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>A good understanding of low-level access of the hardware.</li>
	<li>A good understanding of FreeBSD device drivers.</li>
	</ul>
	</desc>
	</idea>

	<idea id="psched" class="soc">
	<title>Geom-based Disk Schedulers</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:luigi@freebsd.org">Luigi Rizzo</a></p>
	<p>In a 2005 GSoC project, "Pluggable Disk Schedulers", Emiliano
	Mennucci explored the feasibility of pluggable disk schedulers
	for FreeBSD. The project was successful, but we could not explore
	certain approaches (e.g. "anticipation", where requests are delayed
	hoping that some future ones can served without a seek) due to
	architectural limitations the kernel had at the time.
	</p>
	<p>
	Since then, the GEOM infrastructure has become available on FreeBSD
	for interacting with disk I/O requests. GEOM has enabled us to
	work on disk schedulers in a much more flexible way, allowing a
	much faster development of disk scheduling algorithms. With
	Fabio Checconi, we have developed a prototype
	implementation of some anticipatory schedulers, see
	<a href="http://info.iet.unipi.it/~luigi/FreeBSD/#geom_sched">GEOM_SCHED</a>.
	</p>
	<p>
	GEOM_SCHED works within the geom layer, i.e. above the device driver
	where queueing of requests may actually occur. The way GEOM_SCHED
	does scheduling is by limiting the number of outstanding requests
	to the device, and the performance implications of this approach
	need to be measured. An alternative approach is to push the
	scheduler (using the same algorithms developed in GEOM_SCHED,
	and most likely the same code) within the device drivers. This less general
	(as it needs to be replicated in all drivers) but it may be
	an interesting thing to do e.g. for some popular device drivers
	such as ATA.
	</p>
	<p>
	The proposed SoC work can address one or more of the following
	aspects:
	<ul>
	<li>implement suitable classifiers for disk requests;</li>
	<li>implement techniques for the auto-tuning of
	the scheduler parameters;</li>
	<li>measure the performance implications
	of doing scheduling above the device driver, and possibly design
	and implement a suitable mechanism to push the GEOM_SCHED
	module within the device driver itself.</li>
	</ul>
	Ultimately, we expect to end up with a production quality subsystem
	for use in FreeBSD.
	</p>
	<p><strong>References</strong>: <a
	href="http://wiki.freebsd.org/moin.cgi/Hybrid">The Pluggable Disk
	Schedulers SoC project</a>, <a
	href="http://www.happyemi.org/hybrid/">Patches</a></p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>Knowledge of GEOM (or interest in getting familiar with it).</li>
	</ul>
	</desc>
	</idea>

	<idea id="trussprocfs">
	<title>Remove procfs dependencies</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:cognet@FreeBSD.org">Olivier Houchard </a></p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>C knowledge.</li>
	<li>Understanding of kernel debugging interfaces.</li>
	</ul>
	</desc>
	</idea>

	<idea id="suspend">
	<title>Suspend to disk</title>

	<desc>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of C.</li>
	<li>Understanding of the hardware/software interface.</li>
	<li>A laptop that works with ACPI.</li>
	<li>Kernel awareness.</li>
	</ul>
	</desc>
	</idea>

	<idea id="bootcode">
	<title>Sync FreeBSD i386 boot code with DragonFly</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:jhb@FreeBSD.org">John Baldwin</a></p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Ability to read and understand foreign C code.</li>
	<li>Ability to write C code.</li>
	<li>Knowledge of i386 assembly.</li>
	<li>Knowledge of BIOS interfaces.</li>
	<li>Knowledge of low-level boot behavior.</li>
	</ul>
	</desc>
	</idea>

	<idea id="optreg">
	<title>Make optional kernel subsystems register themselves via sysctl</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
	<p>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 <a
	href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/sysctl.h.diff?r1=1.154;r2=1.155;f=h">FEATURE
	macro</a> so that the userland can easily query whether a given
	feature is present. So far not all kernel features are using this
	infrastructure.</p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of C.</li>
	<li>Kernel awareness.</li>
	</ul>
	</desc>
	</idea>

	</category>

	<category>
	<title>Networking</title>

	<idea id="csup">
	<title>csup improvements</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:lulf@FreeBSD.org">Ulf Lilleengen</a></p>
	<p><strong>URL's</strong>: <a
	href="http://mu.org/~mux/csup.html">csup homepage</a>, <a
	href="http://www.freebsd.org/cgi/cvsweb.cgi/projects/csup/">CVSweb</a>
	</p>
	<p>csup is a port of the cvsup high-speed CVS repository replication
	application from the original Modula-3 to the C lanaguage. It is now
	distributed with FreeBSD, but is missing some important features that would
	make useful projects to work on:</p>
	<ul>
	<li>Add support for authentication.</li>
	<li>Working rsync support.</li>
	<li>Optimize rcsfile handling.</li>
	<li>Create a library out of the ports that might be of use in a C language
	csupd.</li>
	<li>Add support for shell commands sent by the server.</li>
	<li>Add missing support for various CVSup options: -D, -a (requires
	authentication support), -e and -E (requires shell commands support) and the
	destDir parameter.</li>
	<li>Work on a new csupd.</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of C.</li>
	<li>Good knowledge of POSIX standards.</li>
	<li>Ability to work with multi-threaded applications.</li>
	</ul>

	</desc>
	</idea>

	<idea class="soc" id="tcpipreg">
	<title>TCP/IP regression test suite</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	href="mailto:gnn@FreeBSD.org">George V. Neville-Neil</a></p>

	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong TCP/IP knowledge.</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc2008" id="passivelibpcapdetector">
	<title>Passive libpcap based TCP session anomaly detector</title>

	<desc>
	<p><strong>Technical contact</strong>: <a href="mailto:andre@FreeBSD.org">Andre Opperman</a>.</p>

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

	<p><strong>Difficulty</strong>: Medium, good familiarity with the TCP RFCs is
	necessary and detection of many edge cases has to be implemented correctly.</p>
	</desc>
	</idea>

	<idea id="wpa2preauth" class="soc">
	<title>WPA2 preauthentication in hostapd</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:sam@FreeBSD.org">Sam Leffler</a></p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of C.</li>
	<li>Wireless networking fundamentals.</li>
	<li>WPA-capable wireless network setup.</li>
	</ul>
	</desc>
	</idea>

	<idea id="80211testing" class="soc">
	<title>802.11 Fuzzing and Testing</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:sam@FreeBSD.org">Sam Leffler</a></p>
	<p>Build a "packet fuzzer" tool that can be used to build test suites to
	improve reliability of the 802.11 code against garbage data. There are
	various tools out but we're not aware of any good ones that work with 802.11
	and are generally available. The basic idea is to write a packet
	injector/playback tool that's driven by a scripting language. Then you
	need to build up a database of test cases. It's also possibly important
	to do time-based playback.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of C.</li>
	<li>Wireless networking fundamentals.</li>
	<li>WPA-capable wireless network setup.</li>
	</ul>
	</desc>
	</idea>

	- <idea class="soc" id="sctp">
	+ <idea id="sctp">
	<title>SCPS, Space Communication Protocol Standards</title>

	<desc><p><a href="http://www.scps.org">SCPS</a> 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.)</p>
	</desc>
	</idea>
	</category>

	<category>
	<title>Ports</title>
	<idea id="ports-db" class="soc2008">
	<title>Add .db support to pkg_tools</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
	<p>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).</p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C.</li>
	<li>Basic understanding of the use of berkeley db.</li>
	</ul>
	</desc>
	</idea>

	<idea id="ports-cleanup-use">
	<title>Cleanup of USE and WITH variables</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:erwin@FreeBSD.org">Erwin Lansing</a></p>
	<p>Make these more consistent. WITH_* should be user-settable
	variables while USE_* only is for internal use in the ports.</p>
	<p><strong>Requirement</strong>:</p>
	<ul>
	<li>Strong knowledge of shell and make code.</li>
	<li>A basic understanding of the inner workings of the ports tree.</li>
	</ul>
	</desc>
	</idea>

	<idea id="ports-pkgtools">
	<title>Package tools improvements</title>

	<desc>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of C code.</li>
	<li>A basic understanding of the inner workings of the ports tree.</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc2008" id="ports-parallel">
	<title>Parallelization in the Ports Collection</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:pav@FreeBSD.org">Pav Lucistnik</a></p>

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

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

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

	<p><strong>Requirements</strong>:</p>

	<ul>
	<li>Strong knowledge of make and shell code.</li>
	<li>Strong knowledge of C code.</li>
	<li>Good understanding of the inner design of the Ports Collection.</li>
	</ul>
	</desc>
	</idea>

	<idea id="ports-license-audit" class="soc2008">
	<title>Ports license auditing infrastructure</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:kris@FreeBSD.org">Kris Kennaway</a>, <a
	href="mailto:brooks@FreeBSD.org">Brooks Davis</a></p>

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

	<p><strong>Requirements</strong>:</p>

	<ul>
	<li>Familiarity with bsd.port.mk and related ports collection
	infrastructure.</li>
	</ul>
	</desc>
	</idea>

	<idea id="fat-pkgs" class="soc">
	<title>Complete (a.k.a. Fat) packages</title>
	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:brooks@FreeBSD.org">Brooks Davis</a></p>
	<p>When bootstrapping systems it would be useful to be able to
	create a single package file that contains one or more packages
	and all the required dependent packages. This is conceptually
	similar to, but different from PC-BSD's PBI package format.
	PBI's contain a private copy of all dependencies, fat packages
	would contain each individual package and once installed it would
	be as though each package was individually installed in the usual
	manner.</p>
	<p>This project would consist of additions to the pkg_tools
	to support creation and installation of a new package file format
	and to ports to build these packages.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of C code.</li>
	<li>A basic understanding of the inner workings of the ports tree.</li>
	</ul>
	</desc>
	</idea>

	</category>

	<category>
	<title>Security</title>
	<idea id="auditkernel" class="soc">
	<title>Audit kernel event sources</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
	<p>
	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 <a
	href="http://www.trustedbsd.org/docs.html">TrustedBSD Documentation Page</a>.
	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).
	</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>Familiarity with concurrent programming techniques.</li>
	<li>General understanding of TCP/IP firewalls.</li>
	<li>Willingness to read the CC/CAPP specification.</li>
	</ul>
	</desc>
	</idea>

	<idea id="distribaudit" class="soc2007">
	<title>Distributed audit / log shipping daemon</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a><br />
	<strong>WIP</strong>: <a
	href="http://wiki.freebsd.org/DistributedAuditDaemon">http://wiki.freebsd.org/DistributedAuditDaemon</a></p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong (portable) C programming skills.</li>
	<li>Knowledge of the audit subsystem.</li>
	<li>OpenSSL knowledge a plus.</li>
	</ul>
	</desc>
	</idea>

	<idea id="libfetchauth">
	<title>Libfetch authentication support</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:phk@FreeBSD.org">Poul-Henning Kamp</a></p>
	<p>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.</p>
	</desc>
	</idea>

	<idea id="mac" class="soc">
	<title>Mandatory Access Control</title>
	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>Familiarity with OS security policies, including discretionary and
	mandatory access control.</li>
	<li>Familiarity with concurrent programming techniques.</li>
	<li>Willingness to read the CC/CAPP specification.</li>
	</ul>
	</desc>
	</idea>

	<idea id="securityregression" class="soc">
	<title>Security regression tests</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
	<p>
	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 <a
	href="http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/regression/">FreeBSD
	regression test tree</a>, but they are both incomplete and and inadequate.
	New tests must be created; existing tests must be completed and updated.
	</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>High tolerance for writing test code.</li>
	<li>High tolerance for reading API specifications.</li>
	<li>Rigorous and devious mindset.</li>
	</ul>
	</desc>
	</idea>

	<idea id="auditjail" class="soc">
	<title>Audit and Jail</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	href="mailto:csjp@FreeBSD.org">Christian Peron</a></p>
	<p>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:</p>
	<ul>
	<li>teach the audit kernel code how to handle the security
	properties of jails,</li>
	<li>implements independent audit configurations and a trail for
	each jail (possibly in addition to a global jail),</li>
	<li>tags audit records with BSM zone tags to indicate which jail
	they came from,</li>
	<li>write a test suite to confirm that it all works properly.</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	</ul>
	</desc>
	</idea>

	<idea id="auditparse" class="soc">
	<title>A New Audit Parsing API</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	href="mailto:trustedbsd-audit@TrustedBSD.org">TrustedBSD audit
	mailing list</a></p>

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

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

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>Past coursework or reading in the area of computer security.</li>
	</ul>
	</desc>
	</idea>

	<idea id="bsmconvert" class="soc">
	<title>NT/Linux to BSM Conversion Tool</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	href="mailto:trustedbsd-audit@TrustedBSD.org">TrustedBSD audit
	mailing list</a></p>

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

	<p>This task would create BSD-licensed conversion tools to import
	audit trails from other systems and convert them to BSM format so
	that they can be inspected and managed using the OpenBSM tool set.
	This would require the creation of BSD-licensed parsers for audit
	trail formats of interest, designing and documenting a semantic
	mapping to the BSM trail format, and writing conversion utilities
	using the new parsers, semantic mapping, and BSM generation
	routines in OpenBSM. A key part of this work would be to
	rigorously understand and document the mapping and its limitations
	(for example, perhaps some Windows NT concepts can't be represented
	in BSM in a natural way, such as larger SID than UID fields, which
	is important information for anyone using BSM trails from NT
	systems). A test suite is also required.</p>

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>Past coursework or reading in the area of computer security.</li>
	</ul>
	</desc>
	</idea>

	<idea id="appaudit" class="soc">
	<title>Application-Specific Audit Trails</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
	href="mailto:trustedbsd-audit@TrustedBSD.org">TrustedBSD audit
	mailing list</a></p>

	<p>Currently, FreeBSD's audit trail support is a system-level
	facility, intended to track system-level security events. However,
	as the affordability of computers has gone up, they are
	increasingly single-application systems, and applications are
	increasingly playing a role in the Trusted Code Base (TCB) of
	larger integrated computing systems. As such, it is desirable to
	support reliable and secure auditing of application events that do
	not correspond to the traditional TCB components, such as events
	from databases, web servers, or virtual machines. However, these
	events need to be handled separately, as they have quite different
	security and selection requirements.</p>

	<p>This task would extend the FreeBSD kernel's audit framework to
	allow multiple concurrent audit trails to be maintained, reflecting
	different "slices" of the system. The base slice would be the
	existing system audit trail, submitted to by the kernel itself, as
	well as using the audit(2) system call, and stored in /var/audit.
	New slices would be represented by named special devices in /dev,
	with ownership and permissions reflecting their desired application
	security properties; each slice would have its own audit worker and
	queue, with its own pipe reliability properties and target trail
	files. This would require extending OpenBSM's auditd and libbsm to
	support multiple trails as well. Finally, two or more sample
	applications would be modified to submit application-level
	auditing, such as the authentication routines in Apache and
	PostgreSQL. This design would have several interesting properties,
	not least that audit trails submitted by applications would be
	protected from application tampering after submission, as the
	kernel would mediate access using the TCB. Analysis of potential
	designs, security issues, documentation, and a test suite are
	required.</p>

	<p>If successful, the results of this work would be integrated into
	the FreeBSD kernel and OpenBSM.</p>

	<p><strong>Requirements</strong></p>
	<ul>
	<li>Strong C programming skills.</li>
	<li>Past coursework or reading in the area of computer security.</li>
	<li>Past coursework in the area of operating system kernels.</li>
	</ul>
	</desc>
	</idea>

	</category>

	<category>
	<title>Userland / Installation Tools</title>

	<idea id="bsdelftools">
	<title>BSD-licensed ELF Tools</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:jkoshy@FreeBSD.org">Joseph Koshy</a>, <a
	href="mailto:kaiw@FreeBSD.org">Kai Wang</a></p>
	<p>Create BSD-licensed versions of ELF processing tools (e.g., <strong>ld</strong>,
	<strong>dbx</strong>, <strong>as</strong> and others) using the ELF(3) and GELF(3)
	API set. Identify overlapping functions in those tools and
	create a library out of the common functions. Identify parts which can be
	generated by tools (e.g., machine code parser generators) to support our Tier-1
	and Tier-2 architectures.</p>
	<p><strong>References</strong>:</p>
	<ul>
	<li><a href="http://elftoolchain.sourceforge.net/">The ELF
	Toolchain Project on SourceForge.Net</a></li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C.</li>
	</ul>
	</desc>
	</idea>

	<idea id="bsdtexttools" class="soc2008">
	<title>BSD-licensed Text-Processing Tools</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:dds@FreeBSD.org">Diomidis Spinellis</a>,
	<a href="mailto:gabor@FreeBSD.org">Gábor Kövesdán</a></p>
	<p>Create/port BSD-licensed versions of one or more of the text processing
	tools that are currently missing from the FreeBSD distribution:
	<strong>sort</strong>,
	<strong>diff</strong>,
	<strong>groff/troff</strong> and the
	<strong>grep</strong> 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.
	</p>
	<p>Regarding groff/troff, there exist the <a
	href="http://heirloom.sourceforge.net/doctools.html">OpenSolaris
	versions</a> at SourceForge which at least do not come with a viral license
	like the current GNU versions we use. Additionally this implementation has
	support for common vector fonts and unicode. If those utilities are
	option-compatible or not has to be analyzed. A port of this is already
	- available as textproc/heirloom-doctools.
	+ available as textproc/heirloom-doctools. Alternativly, OpenBSD's
	+ <a href="http://mdocml.bsd.lv/">mdocml</a> can replace groff's mdoc
	+ functionality and may be sufficent for our purposes.
	</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C.</li>
	</ul>
	</desc>
	</idea>

	<idea id="noswitches">
	<title>Build options improvements</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a>, <a href="mailto:gbell72@rogers.com">Gardner Bell</a></p>
	<p>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 <a
	href="http://cvsweb.freebsd.org/src/tools/build/mk/OptionalObsoleteFiles.inc">covered</a>.
	You can view a list of all switches and what effect they have <a
	href="http://phk.freebsd.dk/misc/build_options/">here</a>.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Time to build and install the world several times.</li>
	<li>A way to determine which files were not touched by an installworld.</li>
	</ul>
	</desc>
	</idea>

	<idea id="kde-freebsd-update" class="soc2007">
	<title>KDE front-ends to the freebsd-update(8)utility</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:cperciva@FreeBSD.org">Colin Percival</a></p>
	<p>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 <a
	href="http://developer.berlios.de/projects/facund">berlios</a>; the QT
	frontend could maybe share common functions/classes and design ideas.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Experience writing KDE applications</li>
	</ul>
	</desc>
	</idea>

	<idea id="ipv6-userland" class="soc">
	<title>IPv6 User Land Cleanup</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:gnn@FreeBSD.org">George V. Neville-Neil</a></p>

	<p>Many userland network utilities do not work correctly with IPv6.</p>
	<ul>
	<li>rpc.statd(8) is not IPv6 clean.</li>
	<li>rpc.rquotad(8) is not IPv6 clean.</li>
	<li>who(1) truncates IPv6 addresses in its output.</li>
	</ul>

	<p>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.</p>
	</desc>
	</idea>

	<idea id="lint">
	<title>lint(1) improvements from OpenBSD</title>

	<desc>
	<p>OpenBSD has some improvements to lint(1) which may be beneficial to
	have.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of C.</li>
	</ul>
	</desc>
	</idea>

	<idea id="libprocnet" class="soc">
	<title>Libprocstat and libnetstat</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of C.</li>
	</ul>
	</desc>
	</idea>

	- <idea id="ndmp" class="soc">
	+ <idea id="ndmp">
	<title>NDMP data server</title>

	<desc>
	<p><strong>URL</strong>: <a
	href="http://www.ndmp.org/">The NDMP Initiative</a></p>
	<p>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.</p>
	<ul>
	<li>Evaluate the existing revisions of the NDMP standard.</li>
	<li>Choose an appropriate revision (after checking of supported versions in
	commercial backup systems).</li>
	<li>Implement at least a NDMP data server.</li>
	<li>Bonus: implement a NDMP tape server (to allow attached tapes to be
	used).</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>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).</li>
	<li>Good knowledge of a programming language which is included in
	the base system.</li>
	<li>Knowledge about UFS snapshots.</li>
	</ul>
	</desc>
	</idea>

	<idea id="prebind">
	<title>Port prebind from OpenBSD</title>

	<desc>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C knowledge (reading and writing).</li>
	</ul>
	</desc>
	</idea>

	- <idea id="pacfile" class="soc">
	+ <idea id="pacfile">
	<title>Proxy auto-config file support for libfetch</title>

	<desc>
	<p>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.</p>

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

	<p><strong>References</strong>:</p>
	<ul>
	<li><a href="http://en.wikipedia.org/wiki/Proxy_auto-config">Wikipedia
	Article on Proxy auto-config</a></li>
	<li><a href="http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html">Proxy
	Auto-Config File Format</a></li>
	</ul>

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of secure C programming.</li>
	</ul>
	</desc>
	</idea>

	<idea id="pxeinstaller">
	<title>PXE Installer</title>

	<desc>
	<p>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.</p>
	<p><a href="mailto:m@FreeBSD.org">Markus Boelter</a> is <a
	href="http://wiki.freebsd.org/MarkusBoelter">working</a> 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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good PXE knowledge.</li>
	</ul>
	</desc>
	</idea>

	<idea id="regression">
	<title>Regression testing system</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:netchild@FreeBSD.org">Alexander Leidinger</a>, <a
	href="mailto:nik@FreeBSD.org">Nik Clayton</a></p>
	<p>Nik has written a regression test infrastructure using Perl. More of
	the regression tests should be made to work with libtap.</p>
	<ul>
	<li>Many of the existing tests should be moved from using assert() to using
	ok() and friends from libtap.</li>
	<li>More regression tests should be written.</li>
	</ul>
	<p>Porting <a href="http://ltp.sf.net/">LTP</a> might also be a good idea.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good knowledge of scripting languages (Perl preferred).</li>
	<li>Good knowledge of software testing.</li>
	</ul>
	</desc>
	</idea>

	<idea id="sysinstall">
	<title>Sysinstall</title>

	<desc>
	<ul>
	<li>Ask for network configuration before install - so you do not have to
	configure the net twice.</li>
	<li>Make a guess of the timezone based upon country and keyboard.</li>
	</ul>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Good C knowledge (reading and writing).</li>
	<li>No fear regarding "naturally grown" code.</li>
	</ul>
	</desc>
	</idea>

	<idea id="taroutmode">
	<title>Tar output mode for installworld</title>

	<desc>
	<p><strong>Technical contact</strong>: <a
	href="mailto:cperciva@FreeBSD.org">Colin Percival</a>, <a
	href="mailto:kientzle@FreeBSD.org">Tim Kientzle</a></p>

	<p>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.</p>
	<p>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.</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>No fear regarding our installation system.</li>
	</ul>
	</desc>
	</idea>

	<idea id="vi-utf8">
	<title>Unicode support in vi</title>

	<desc>
	<p><strong>Technical info:</strong>: on J.R. Oldroyd's
	<a href="http://opal.com/jr/freebsd/unicode.html">Unicode Support on
	FreeBSD</a> page</p>
	<p>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).</p>
	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C.</li>
	</ul>
	</desc>
	</idea>

	<idea id="cron-and-atrun">
	<title>Improve cron(8) and atrun(8)</title>

	<desc>
	<p>Currently, cron(8) and atrun(8) are outdated in their implementation.
	Here are some directions for improvement:</p>
	<ul>
	<li>Update cron(8) to ISC cron with security fixes from OpenBSD.</li>
	<li>Integrate the atrun(8) functionality into cron(8),
	as it was done in NetBSD.</li>
	</ul>

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of the C language and Unix API.</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc" id="wine">
	<title>Improve Wine support in FreeBSD</title>

	<desc><p><strong>Technical contact</strong>:
	<a href="mailto:kris@pcbsd.com">Kris Moore</a></p>

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

	<idea id="bsnmp" class="soc">
	<title>BSNMP enhancements</title>

	<desc><p><strong>Technical contact</strong>:
	<a href="mailto:syrinx@FreeBSD.org">Shteryana Shopova</a>,
	<a href="mailto:bz@FreeBSD.org">Bjoern A. Zeeb</a></p>

	<p>BSNMP is a portable SNMP framework consisting of a daemon,
	modules and tools. It includes libraries that ease
	the development of loadable modules for configuring and
	monitoring various subsystems.
	You can find more information about BSNMP
	<a href="http://wiki.freebsd.org/Bsnmp">on the wiki</a>.
	Some project ideas, but not limited to that list, can be found
	<a href="http://wiki.freebsd.org/BsnmpTODO">here.</a>.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Knowledge of C.</li>
	<li>Some familiarity with SNMP/MIBs desirable.</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc" id="pthread-profile">
	<title>Userspace pthread mutex lock contention profiling and lock
	order verification tool</title>

	<desc><p><strong>Technical contact</strong>: <a
	href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Strong knowledge of C.</li>
	<li>Threading experience.</li>
	<li>Strong debugging skills.</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc" id="freebsd-gnome-networkmanager">
	<title>FreeBSD port of NetworkManager</title>

	<desc><p><strong>Technical contact</strong>: <a
	href="mailto:marcus@FreeBSD.org">Joe Marcus Clarke</a></p>

	<p>This task is to port
	<a href="http://www.gnome.org/projects/NetworkManager/">
	NetworkManager</a> to FreeBSD. Porting NetworkManager
	will also require some core userland changes to FreeBSD,
	especially to ifconfig.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>C programming skills</li>
	<li>Knowledge of the FreeBSD net80211 wireless stack</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc" id="freebsd-gnome-systemtools">
	<title>Fix FreeBSD support in GNOME's system-tools-backends</title>

	<desc><p><strong>Technical contact</strong>: <a
	href="mailto:marcus@FreeBSD.org">Joe Marcus Clarke</a></p>

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>Perl programming skills</li>
	<li>Knowledge of the FreeBSD system configuration</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc" id="freebsd-gnome-hal">
	<title>Extend hal support on FreeBSD</title>

	<desc><p><strong>Technical contact</strong>: <a
	href="mailto:marcus@FreeBSD.org">Joe Marcus Clarke</a></p>

	<p>This task is to add hal support for some additional
	subsystems. In particular FreeBSD is lacking support for the
	ieee1394 (i.e. Firewire), bluetooth, and printer. Adding
	support for these subsystems will require changes to the
	FreeBSD kernel. Those interested should use the latest
	<a href="http://www.marcuscom.com/hal-spec/hal-spec.html">
	HAL Specification</a> as a guide.</p>

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>C programming skills</li>
	<li>Knowledge of the FreeBSD system internals</li>
	</ul>
	</desc>
	</idea>

	<idea class="soc" id="freebsd-amd64-gcc-m32">
	<title>Finish support for compilation of i386 binaries on amd64</title>

	<desc><p><strong>Technical contact</strong>: <a
	href="mailto:kib@FreeBSD.org">Konstantin Belousov</a></p>

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

	<p><strong>Requirements</strong>:</p>
	<ul>
	<li>C and shell programming skills</li>
	<li>Knowledge of the FreeBSD build and installation infrastructure</li>
	<li>Some knowledge of the gcc internals</li>
	</ul>
	</desc>
	</idea>
	</category>
	</ideas>

File Metadata

Mime Type: text/x-diff
Expires: Sun, Aug 9, 12:05 PM (13 h, 13 m)
Storage Engine: blob
Storage Format: Raw Data
Storage Handle: 29371153
Default Alt Text: (79 KB)

No OneTemporaryActions

View Options

File Metadata

Event Timeline

No OneTemporary
Actions