os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/en/projects/ideas/ideas.xml
Konrad Jankowski c5c0b3d41e Remove the collation entry, as the collation will be finished by me soon. 
Reviewed by:	murray
Approved by:	dds (mentor)
2008-11-02 22:48:28 +00:00

2187 lines
85 KiB
XML
Raw Blame History

<?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.89 2008/06/18 06:55:29 ed Exp $
</cvs:keyword>
</cvs:keywords>
<category>
<title>Embedded</title>
<idea id="reduced-size-freebsd" class="soc">
<title>Reduced FreeBSD for Embedded</title>
<desc><p><strong>Technical Contact</strong>: <a
href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
<p>In the Linux world, there are a number of packages available
which will grab a bunch of software, including Linux, the tool
chains, packages, etc and create a firmware image for popular
devices. Since FreeBSD is an integrated system, many of these
elements are present in the base system or the ports tree.</p>
<p>There have been attempts at this problem over the years:
nanobsd, picobsd, and tinybsd are in the tree, Sam Leffler has
his own custom scripts, etc. This project would pick an
approach and use the existing scripts to make it simple to
create images that could be loaded into the firmware of these
devices. Many of the newer devices have 8MB or 16MB flash
parts, so that would be a good size to target for the kernel
and ram disk image. A good way to think of this project is
openwrt for FreeBSD images.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong C and scripting language programming skills.</li>
<li>No fear of the FreeBSD build process.</li>
<li>Good knowledge of how FreeBSD is put together.</li>
<li>Knowledge of the ports system.</li>
</ul>
</desc>
</idea>
<idea id="reduced-size-kernel" class="soc">
<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" class="soc">
<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" class="soc">
<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" class="soc">
<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" class="soc">
<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" class="soc">
<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" class="soc">
<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>
<li>Make msdosfs robust in the presence of unexpected disk removal, since
it is frequently used with removable devices.</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">
<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="soc">
<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" class="soc">
<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>
<li>We need someone to port the DTrace toolkit to FreeBSD. Part of this will
include adding additional probes to the kernel and to userland processes
to do what Sun does in OpenSolaris and also what Apple does in OS X.</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="modrefcnt">
<title>Dynamic module references</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:sam@FreeBSD.org">Sam Leffler</a></p>
<p>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.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Kernel awareness.</li>
</ul>
</desc>
</idea>
<idea id="kernel-linuxemu" class="soc">
<title>Kernel support for linux device drivers</title>
<desc>
<p><strong>Technical contact</strong>: <a href="mailto:luigi@FreeBSD.org">Luigi Rizzo</a></p>
<p>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
<a
href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.</p>
<p>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).</p>
<p>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.</p>
<p>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.</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" class="soc">
<title>Implement and profile algorithms for powerd</title>
<desc>
<p><strong>Technical contacts</strong>: <a
href="mailto:njl@FreeBSD.org">Nate Lawson</a>, <a
href="mailto:bruno@FreeBSD.org">Bruno Ducrot</a></p>
<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 class="soc" 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="usb-update">
<title>Improving the USB stack in FreeBSD</title>
<desc>
<p><strong>Technical contact</strong>: <a href="mailto:luigi@FreeBSD.org">Luigi Rizzo</a></p>
<p>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.</p>
<p>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.</p>
<p>The goal of this project is to improve the FreeBSD stack in one
of the following ways:</p>
<ul>
<li>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;</li>
<li>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.</li>
</ul>
<p>The production of suitable documentation in the source is a key
requirement of the project.</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">
<title>Pluggable Disk Scheduler</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:s223560@studenti.ing.unipi.it">Emiliano Mennucci</a></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>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.</p>
<p>Interested people should also have a look at <a
href="http://lists.freebsd.org/pipermail/freebsd-geom/2007-January/001854.html">
a mail thread about this</a> (Ulf is not working on this) and <a
href="http://www.freebsd.org/cgi/mid.cgi?db=irt&amp;id=20071011022001.GC13480@gandalf.sssup.it">
further discussion</a> of the corresponding GEOM aspects.</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="sensors">
<title>Add support for the sensors framework to more drivers</title>
<desc>
<p>Not many drivers make use of the sensors framework yet. Possible targets
which should be enhanced to use the sensors framework are ATA/SCSI (temperature,
write cache status, ...), GEOM (RAID status, ...), ACPI (temperature,
voltage, ...) and more.</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="trussprocfs">
<title>Remove procfs dependencies</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:mux@FreeBSD.org">Maxime Henrion</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" class="soc">
<title>Suspend to disk</title>
<desc>
<p><strong>Technical contacts</strong>: <a
href="mailto:njl@FreeBSD.org">Nate Lawson</a>, <a
href="mailto:bruno@FreeBSD.org">Bruno Ducrot</a></p>
<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="sysmod" class="soc">
<title>Syscons modularization</title>
<desc>
<p>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.</p>
<p>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.</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 text terminals and terminal emulation.</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>
<idea id="vmalgorithm" class="soc">
<title>VM Algorithm Improvement</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:jeff@FreeBSD.org">Jeff Roberson</a>, <a
href="mailto:alc@FreeBSD.org">Alan Cox</a></p>
<p>The vm uses a splay tree to lookup pages associated with an offset and a
file. This tree structure is space inefficient and cache inefficient for
large objects. This project will be to replace the splay with a dynamic
depth page-table like structure similar to a radix tree. This will improve
large object performance and reduce the size of the vm_page.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Familiarity with concepts of virtual memory and advanced data
structures and algorithms.</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:mux@FreeBSD.org">Maxime Henrion</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>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:</p>
<ul>
<li>Add support for authentication.</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>Add support for CVS mode. This is important for developers, since this
mode sends the actual RCS files themselves. Some parts of this has
already been implemented, such as an RCS parser and an interface to
edit RCS files. The remaining parts for this feature is RCS
correctness testing, protocol correctness testing, fixing bugs and
checking for memory leaks and performance issues.</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="soc2007" id="magtundaemon">
<title>Magic tunnel daemon</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:phk@FreeBSD.org">Poul-Henning Kamp</a>, <a
href="mailto:mharvan@inf.ethz.ch">Matus Harvan</a><br />
<strong>WIP</strong>: <a
href="http://wiki.freebsd.org/mtund">http://wiki.freebsd.org/mtund</a></p>
<p>IP can be tunnelled over IP, UDP, TCP, SSH, DNS, HTTP and many other
protocols, and this means that it is often possible to get a
connection out through a firewall, but each of these encapsulations
require prior setup of a specific program for each encapsulation, and
the user must experiment to decide which one to use at any one time.
The super tunnel daemon should implement pluggable encapsulations and
make it automatically select the most efficient encapsulation that
works at any one time. The user should not notice transitions from one
encapsulation to another, apart from maybe a small delay.</p>
<p>Wanted features (not sorted or prioritized):</p>
<ul>
<li>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.</li>
<li>Plugin architecture for easy addition of further encapsulations.</li>
<li>Failover from one encapsulation to another.</li>
<li>Distinct configuration files for encapsulations which need to be
configured (e.g. proxy, authentication, ...).</li>
<li>Possibility to disable installed encapsulations.</li>
<li>Print/log hints for protocols which require some configuration,
e.g. telling the user to use keys and perhaps the ssh-agent for ssh.</li>
<li>Configurable additional plugin directories (for plugins installed
via the ports collection).</li>
<li>Log how it is able to tunnel the traffic (this also makes it useful
for finding unwanted holes in the configuration of a firewall).</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Good knowledge about networks.</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="soc" 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="wi" class="soc">
<title>Update wi</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:sam@FreeBSD.org">Sam Leffler</a></p>
<p>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.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
<li>No fear of undocumented parts of the kernel.</li>
<li>One wi(4) card and one other wireless device to test against.</li>
</ul>
</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">
<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="soc">
<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-collect-messages">
<title>Collect the pkg-message output</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:pav@FreeBSD.org">Pav Lucistnik</a></p>
<p>Collect the pkg-message output of dependencies and print them together
after the whole build finishes.</p>
<p>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)).</p>
<p><strong>Requirements:</strong></p>
<ul>
<li>Knowledge of shell and make coding, and basic overview of how
ports works.</li>
<li>Basic knowledge of C.</li>
</ul>
</desc>
</idea>
<idea id="ports-options">
<title>Improvements of OPTIONS</title>
<desc>
<p>The current OPTIONS infrastructure can be improved in several ways.</p>
<ul>
<li>It should be possible to define OPTIONS after bsd.ports.pre.mk.</li>
<li>Add an API to override the current curses based interface with
a different GUI, e.g. zenity/gdialog instead of dialog.</li>
<li>More room for a description in the OPTIONS dialog - possibly some
sort of help dialog could be provided for each option, like in
sysinstall.</li>
<li>Better handling of cases where OPTIONS are changed/added/removed
between upgrades.</li>
<li>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.</li>
<li>Other types of OPTIONS controls - A text box in particular would be
useful for entering variables that need real values.</li>
<li>The possibility for mutually exclusive OPTIONS.</li>
<li>Bugfixes:
<ul>
<li>If you attempt to run make config for a port with
${PKGNAMEPREFIX} defined, the make config process will error out
with:<br/>
===> Using wrong configuration file /path/options/file<br/>
The solution is to define LATEST_LINK to be prefix-${PORTNAME},
but this should be done internally.</li>
</ul></li>
</ul>
<p><strong>Requirements</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="soc" 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-upgrade">
<title>Utility for safe updating of ports in base system</title>
<desc>
<p>Also known as <em>rewrite portupgrade in C</em>.</p>
<p>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:</p>
<ul>
<li>fixing @pkgdep records in +CONTENTS file</li>
<li>fixing +REQUIRED_BY records</li>
<li>storing old copies of shared libraries after shmajor number
change in /usr/local/lib/compat/pkg</li>
<li>upwards and downwards recursive modes</li>
<li>ability to work on a complete local ports tree without valid
INDEX file</li>
<li>ability to work on a remote (ftp) package set without local
ports tree</li>
</ul>
<p>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.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Basic understanding of the Ports Collection design.</li>
<li>Good skills writing C code.</li>
<li>Ability to read Ruby will help.</li>
</ul>
</desc>
</idea>
<idea id="ports-license-audit" class="soc">
<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="nfsv4acls" class="soc">
<title>NFSv4 ACLs</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
href="mailto:pjd@FreeBSD.org">Pawel Jakub Dawidek</a></p>
<p>The NFSv4 RFC and follow-on drafts specify a new Access Control
List (ACL) format loosely based on NTFS ACLs. This format is not
directly compatible with existing POSIX.1e ACLs, but has been
adopted by a number of recent UNIX file systems (including Apple's
HFS+ and Sun's ZFS file systems) in order to improve Windows
compatibility. This project is multi-part:</p>
<ul>
<li>research current specifications and implementations of
NFSv4 ACLs,</li>
<li>implement an ACL library in userspace,</li>
<li>port the ACL implementation to the kernel and enhance the
kernel ACL infrastructure to support NFSv4 ACLs,</li>
<li>implement optional NFSv4 ACL support on UFS2 and ZFS,</li>
<li>investigate NFSv4 ACL support for Samba and smbfs,</li>
<li>implement a test suite exercising relevant aspects of NFSv4
ACL implementation, both basic rule evaluation and its
integration with the nominally incompatible UNIX owner, group,
and mode.</li>
</ul>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong C programming skills.</li>
<li>Tolerance for IETF specifications.</li>
<li>Appreciation for the nasty subtleties of access control.</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>
</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="soc">
<title>BSD-licensed Text-Processing Tools</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:dds@FreeBSD.org">Diomidis Spinellis</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.
</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">
<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">
<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="schedgraph" class="soc">
<title>Schedgraph Improvements</title>
<desc>
<p><strong>Technical contact</strong>: <a href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>
<p>Schedgraph is a tool for analyzing scheduling events and visually
displaying them in such a way that they reveal interesting kernel
and application performance problems. It is written in python/tkinter
and interfaces with the kernel via the generic KTR kernel tracing
system. Schedgraph is in need of many features and general
improvements such as the ability to synchronize timestamps in SMP
systems, plotting time spent spinning on spinlocks, improved visual
appearance, faster graphing time, and many other features. Access to
an 8 processor FreeBSD machine will be provided to implement advanced
SMP features.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Working understanding of python.</li>
<li>Some familiarity with any widget set recommended.</li>
<li>Ability to recompile and reconfigure a FreeBSD kernel.</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="sntp">
<title>SNTP</title>
<desc><p><strong>Technical contact</strong>: <a
href="mailto:stenn@ntp.org">Harlan Stenn</a> (NTP Project)</p>
<p>This task is to create an SNTP implementation; this program will
be a "reference" implementation of SNTP, based on the latest
NTPv4 document. SNTP is first and foremost a lightweight NTP
client. It will use GNU AutoGen (like the rest of the NTP
programs) for its options processing. While an SNTP
implementation may talk directly to a reference clock, the core
requirement for this effort is to be a simple client
implementation. We have an existing implementation based on an
older specification. It contains functionality that is obsolete.
You could write a ground-up implementation or take the existing
one and hack it in to shape, or some combination of the two.</p>
<p>Related topics: <a href="http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt">draft-ietf-ntp-ntpv4-proto-09.txt</a></p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C 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>
</category>
</ideas>
Reference in a new issue View git blame Copy permalink