os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/en/projects/ideas/ideas.xml
Ulrich Spörlein d720e0a3e8 Squash typos. 
Found via:	codespell (most of them)
2011-06-02 12:29:12 +00:00

2184 lines
87 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.165 2011/05/15 19:34:14 uqs 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 aggressively 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="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="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="mips-superpages">
<title>Add super page support to MIPS</title>
<desc><p><strong>Technical Contact</strong>: <a
href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
<p>Superpage support exists only for x86-based architectures at the
moment. MIPS hardware supports a number of different page sizes
on a per page basis. This could be used to implement superpages
for MIPS(which just uses two sizes: 4k chunks and 4M chunks). The
vm system supports it generically for all platforms, but the pmap
for each platform must complete the implementation. Fortunately,
superpages were MFC'd as one huge commit into FreeBSD 7.x, so
finding the relevant changes that need to be made to the mips pmap
won't be starting from scratch.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong C programming skills</li>
<li>Strong kernel skills</li>
<li>Strong VM 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="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="portext2fs" class="soc2009">
<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="ext34fs" class="soc">
<title>Enhance FreeBSD ext2fs to support preallocation, ext3, and
ext4</title>
<desc><p><strong>Technical contact</strong>: <a
href="mailto:lulf@FreeBSD.org">Ulf Lilleengen</a></p>
<p>During Google Summer of Code, Aditya Sarawgi created a GPL-free
implementation of ext2fs for FreeBSD, which has now been completed.
However, there are several avenues for potential further work:</p>
<ul>
<li>Implement preallocation in ext2fs; the GPL-licensed preallocation
code present in the previous implementation was removed, but it may
well be desirable to add it back. This should be driven by
benchmarking and performance analysis.</li>
<li>Update ext2fs to be able to read ext4 file systems, and possibly
add other functionality from newer ext file system versions.</li>
</ul>
</desc>
</idea>
<idea id="portntfs" class="soc">
<title>Port Darwin's NTFS implementation</title>
<desc>
<p>The <a href="http://www.opensource.apple.com/source/ntfs/ntfs-65.2/kext/">Kernel</a>
part of NTFS implementation on Mac OS X is dual licensed under both a
3-clause BSD and GPL license, and supports writing.</p>
</desc>
</idea>
<idea id="portudf" class="soc">
<title>Port NetBSD's UDF implementation</title>
<desc><p><strong>Technical Contact</strong>: <a
href="mailto:avg@FreeBSD.org">Andriy Gapon</a></p>
<p><strong>Technical references</strong>:
M. McKusick, G. Neville-Neil, <a
href="http://www.awprofessional.com/titles/0201702452">
The Design and Implementation of the FreeBSD Operating System
</a>
(ISBN 0-201-70245-2), <a
href="http://www.osta.org/specs/pdf/udf260.pdf">UDF 2.60 OSTA
Specification </a>
, <a
href="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf">
Volume and File Structure for Write-Once and Rewritable Media
using Non-Sequential Recording for Information Interchange
</a></p>
<p>FreeBSD has an implementation of the UDF filesystem
but it is quite aged and doesn't support many features from newer UDF
revisions (&gt;=2.01), it's also readonly.
NetBSD implementation by Reinoud Zandijk supports most of UDF features
and has write support too. Initial port could be readonly so that
at least newer pre-authored media (e.g. BD) is accessible.
Porting write support is a bit trickier.
</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C programming.</li>
<li>Basic understanding of VFS, buffer cache and filesystem implementation.</li>
</ul>
</desc>
</idea>
<idea id="colocation">
<title>Implement co-location for UFS2</title>
<desc><p>While FreeBSD's FFS includes many advanced features, such as
snapshots and soft updates, Greg Granger <a
href="http://www.ece.cmu.edu/~ganger/papers/cffs.html">has 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:kib@FreeBSD.org">Konstantin Belousov</a></p>
<p>FreeBSD 6.0 introduced an multi-processor scalable Virtual File
System (VFS) Framework, allowing file systems to operate without the
Giant lock. Many of the most commonly used file systems have been
adapted to be MPSAFE (i.e., not reliant on Giant), such as UFS, the
NFS client and server, UDF, cd9660, ZFS, and most recently the
msdosfs (FAT) file system. However, in order to remove the
compatibility shims permitting a file system to declare itself
non-MPSAFE, all file systems must be converted. The list of
remaining file systems includes ntfs, hpfs, coda, smbfs, and ncpfs.
This project idea is to take one or more file systems and convert
them to use their own locking, rather than relying on the Giant
lock. In some cases, this requires also adapting underlying
infrastructure: for example, smbfs relies on the netsmb RPC
framework, and ncpfs on the netcp RPC framework, both of which will
also require conversion.</p>
</desc>
</idea>
</category>
<category>
<title>Kernel</title>
<idea id="fifo-optimizations" class="soc2009">
<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">Joseph Koshy</a>,
href="mailto:gnn@FreeBSD.org">George Neville-Neil</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 have 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:attilio@freebsd.org">Attilio Rao</a>,
<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>Work is currently in progress on this and is undergoing review.
It is not complete, but interested parties should contact Attilio
before beginning work.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Understanding of kernel VM.</li>
</ul>
</desc>
</idea>
<idea id="dynamiccpu" class="soc">
<title>CPU online/offline project</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:jhb@FreeBSD.org">John Baldwin</a>, <a
href="mailto:attilio@FreeBSD.org">Attilio Rao</a></p>
<p>The project would need to extend the current CPU states of
absent and present to include absent, offline, and online. A
set of event handlers (probably using EVENTHANDLER(9)) will
need to be created to allow subsystems to be notified of CPU
state changes. At a minimum, the functionality of the
current 'hlt_cpus_mask' should be reimplemented in both the
4BSD and ULE schedulers using this mechanism. Note that the
ability to disable all but one thread within a core must
still be supported easily. (This is currently done on x86
via the machdep.hyperthreading_allowed sysctl.) Each
subsystem that uses CPU_ABSENT() will need to be evaluated to
see if it needs updating to handle online vs offline CPUs.
Further improvements may include teaching UMA to free per-CPU
buckets when a CPU is taken offline.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Experience with multi-threaded programming.</li>
<li>Experience with kernel programming.</li>
</ul>
</desc>
</idea>
<idea id="scalableprimitives" class="soc">
<title>SMP scalability improvements for core primitives</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:attilio@FreeBSD.org">Attilio Rao</a>, <a
href="mailto:jhb@FreeBSD.org">John Baldwin</a>.</p>
<p>FreeBSD SMP scalability has improved dramatically over the last
ten years as a result of the now-complete SMPng project, which
converted FreeBSD from a single Giant kernel lock to fine-grained
locking and strong 8-core scalability. As commodity hardware is
now reaching 16-24 cores, some low-level primitives in the SMP
implementation must be revisited. In particular, 32 or 64-CPU
limits are encoded in the CPU mask primitive (cpumask_t), and
spin locks offer higher than desired cache line contention as well
as unfairness. This project would combine these two related tasks
by improving the expressibility of CPU masks and per-CPU objects
and improving the scalability of the spinlock implementation. It
is especially important that the latter portion of the work be
driven by real-world measurement using workloads that trigger the
specific problem, and experimentation with primitives across
several types of hardware.</p>
<p>Note: a spinlock backoff patch has already been proposed, but not
yet properly evaluated, and would make a good starting point for
this work.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Experience with multi-threaded programming.</li>
<li>Experience with kernel programming.</li>
</ul>
</desc>
</idea>
<idea id="umtx">
<title>Rewrite umtx - userspace mutex system calls</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:attilio@FreeBSD.org">Attilio Rao</a></p>
<p>umtx is the underbelly of the FreeBSD pthreads synchronization
primitives, allowing kernel-assisted sleeping, wakeups, priority
propagation, and other features supporting efficient mutexes and
reader-writer locks in userspace. As kernel features have evolved
(such as the addition of a sleepqueue primitive), hardware
scalability has grown, and application-writer expectations have
changed, some weaknesses have come to light. In particular, there
are concerns about overhead and scalability with highly-threaded
applications. This project would profile and evaluate the existing
system call service provided by umtex, and consider cleanups,
optimizations, and the application of newer algorithms to improve
functionality and performance. The effectiveness of the rewrite
would be demonstrated through careful testing with sensitive
workloads, such as MySQL on 16-core systems.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Experience with multi-threaded programming.</li>
<li>Experience with kernel programming.</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:sson@FreeBSD.org">Stacey Son</a>, <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</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
provides strong kernel functionality, but significant work remains to be
done. Some ideas for projects:</p>
<ul>
<li>It would be preferable to have a BSD-licensed CTF implementation, but
this requires careful documentation of the specification and a clean-room
implementation.</li>
<li>Tracing of user processes is not supported, and is a highly desirable
feature.</li>
<li>It would be quite useful to track changes to DTrace in OpenSolaris since
the initial port, merging enhancements and bug fixes that apply to
FreeBSD.</li>
<li>There has been some work to add static trace points for kernel
subsystems, such as VFS, the MAC Framework, privilege checking, etc.
However, it would be useful to add further static trace points to the
network stack, disk I/O subsystems, GEOM, etc. It would be useful to do
this in a similar way to Solaris so that Solaris monitoring scripts could
be used in FreeBSD.</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><strong>Technical contact</strong>: <a
href="mailto:kib@FreeBSD.org">Konstantin Belousov</a></p>
<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 to support
building Linux device drivers on FreeBSD.
This was done through an in-kernel emulation layer, which
implements part of the linux kernel API on top of the FreeBSD
kernel API. The initial implementation was good enough to
support a few USB webcam drivers, and is documented
<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" class="notsoc">
<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="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="per-job-limits" class="soc">
<title>Collective limits on set of processes (a.k.a. jobs)</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:brooks@freebsd.org">Brooks Davis</a></p>
<p>In SGI's Irix operating system, there is a concept of a job which is
a collection of processes. These processes share a set of resource
limits similar to those accessible through the set/getrlimit and
getrusage system calls. Schedulers such as Sun Grid Engine currently
implement tracking the processes that make up a job and enforcing
collective limits on them in an adhoc manner. Having first class
kernel support would be useful.</p>
<p>It seems most likely that implementing something like the Irix
interface would be the most useful approach since that would enable us
to leverage existing code. Implementers will need to make sure that
the job construct has no negative performance implications when not
enabled (ideally, processes that are not part of jobs should be
unaffected) and quantify the impact on performance when enabled.</p>
<p><strong>References</strong>: <a
href="http://techpubs.sgi.com/library/tpl/cgi-bin/browse.cgi?cmd=search&amp;coll=0650&amp;db=man&amp;pth=&amp;srch=jid_t&amp;searchpth=man&amp;rpt=20">Irix
Man Pages mentioning jid_t</a></p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Kernel awareness.</li>
<li>Ability to implement functionality from interface specifications.</li>
</ul>
</desc>
</idea>
<idea id="psched" class="soc2009">
<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="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>
<idea id="efi">
<title>EFI support for FreeBSD/i386 and FreeBSD/amd64</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>
<p>Finish EFI support on the i386/amd64 ports. Final work
should be able to boot a FreeBSD kernel into single user
mode, at least.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Deep understanding of the boot process and EFI.</li>
<li>A system running EFI 1.0 (Intel Macs, for example)</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 language. It is now
distributed with FreeBSD, but is missing some important features that would
make useful projects to work on:</p>
<ul>
<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, -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>, <a
href="mailto:rpaulo@FreeBSD.org">Rui Paulo</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>,<a
href="mailto:rpaulo@FreeBSD.org">Rui Paulo</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 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>
<idea id="tcp-uto" class="soc2009">
<title>Implement TCP UTO</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>
<p>Implement TCP UTO (User Timeout Option) as defined by RFC
5482.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C and TCP.</li>
<li>Able to understand the FreeBSD TCP/IP stack.</li>
<li>A testbed with at least two machines.</li>
</ul>
</desc>
</idea>
<idea id="multiqbpf" class="soc">
<title>Multiqueue BPF support and other BPF features</title>
<desc><p><strong>Technical contact</strong>: <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>The Berkeley Packet Filter (BPF) allows packet capture filters to
be compiled into a bytecode that is either interpreted by a kernel
virtual machine, or compiled into native machine code via a JIT and
executed in in-kernel. Historically, the origin of packets has
been the network interface, with each (synthetic) BPF device
attached to exactly one NIC as requested by the application (for
example, tcpdump). However, network interfaces have become
significantly more complicated, and BPF has had to grow to support
new features, such as Data Link Types (DLTs), in which BPF devices
can tap network processing at different layers. This task would
involve teaching BPF about a further dimension in network interface
complexity: multiple input and output queues.</p>
<p>Modern 10gbps, and even 1gbps, network cards support multiple
queues for various reasons: at first quality of service (QoS)
differentiation in processing, but now especially to improve
parallelism in network processing by distributing work to many CPUs
on input. This same technica can also accelerate packet capture,
but BPF currently doesn't know this. In this project, BPF would be
enhanced to be aware of individual input and output queues on a NIC,
which means providing network stack abstractions for these concepts,
visible today only within device drivers. Userspace threads might
then use enhanced ioctl(2)s to query the set of available queues
and attach to one or more. Applications seeking maximum parallelism
could open (n) devices, attaching each to a queue, and executing
with appropriate CPU affinity. Ideally this would involve neither
lock nor cache line contention throughout the entire stack, from
device driver to userspace delivery.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Experience with multi-threaded programming.</li>
<li>Experience with kernel programming.</li>
<li>Familiarity with the TCP/IP protocol suite.</li>
</ul>
</desc>
</idea>
<idea id="80211sim" class="soc">
<title>Implement a simulated 802.11 wireless radio</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rpaulo@FreeBSD.org">Rui Paulo</a></p>
<p>The FreeBSD 802.11 layer, net80211, implements a broad range of
advanced functionality: station, access point, virtual access
point, mesh networking, authentication/encryption, and more. This
task implements a net80211 driver simulating a wireless radio in
order to allow protocol-layer testing without the hassle of real
live hardware limitations: interference, signal propagation, and
regulatory domains. The driver should let the user specify a
number of radios to be simulated, with an eye towards future work
to simulate physical properties.</p>
<p>A useful reference for this work would be the notionally similar
mac80211_hwsim driver in Linux
(http://linuxwireless.org/en/users/Drivers/mac80211_hwsim), which
might provide a model in some areas of the work, and has similarly
been used on that platform to test hostapd/wpa_supplication.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good knowledge of C.</li>
<li>Wireless networking fundamentals.</li>
</ul>
</desc>
</idea>
</category>
<category>
<title>Ports</title>
<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 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>
<idea id="ports-performance" class="soc">
<title>Performance improvement of the Ports system</title>
<desc>
<p>A number of tasks of the Ports system can take quite a long time
to perform. Some are well known for traversing each and every port
in the tree, e.g. building INDEX, which does not scale well with
the number of ports being added to the collection.</p>
<p>Detailed profiling of the most used commands in the ports
framework needs to be done to analyze the bottlenecks and identify
possible solutions. Refactoring of the main file bsd.ports.mk
is also necessary to improve code readability, but not at the
cost of performance.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of make and shell code.</li>
<li>Good understanding of the inner design of the Ports Collection.</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="soc">
<title>Distributed audit / log shipping daemon</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
href="mailto:simon@FreeBSD.org">Simon Nielsen</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="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="mac_policy" class="soc">
<title>Path-based file system MAC policy</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</a>, <a
href="mailto:trustedbsd-discuss@TrustedBSD.org">TrustedBSD discuss
mailing list</a></p>
<p>The TrustedBSD MAC Framework makes it easy to extend the FreeBSD
kernel security model using pluggable modules, which has provided
support for "traditional" mandatory access control, as well as
allowed a number of companies to build local security policy
extensions for workstation, server, and appliance products; one
such example is Apple's "Seatbelt" policy for Mac OS X. However,
the base system MAC policies are difficult to use, primarily
because they either don't extend security meta-data (ugidfw) or
they require extensive labeling (Biba, MLS). This project idea
involves crafting a new OS security policy extension along the
lines of ugidfw, the file system firewall, but using path names
instead of existing file properties to manage protection. This
requires careful thinking about what a file system path "is" in
the UNIX environment, as well as regarding what sorts of
policies would be useful.</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>
</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 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="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="soc2009">
<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>
<idea id="privmodel" class="soc">
<title>New kernel privilege model</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>FreeBSD uses a largely standard UNIX privilege model, granting
special OS rights to processes with an effective uid of 0.
Exceptional behavior lies in securelevel (restricting root based
on a global or per-jail level), Jail (limiting certain rights to
ensure safe containment for a jailed root user), and the ability
for the MAC Framework to augment privilege decisions. However,
as of FreeBSD 7.0, privilege decisions internal to the kernel
have been made with respect to a large set of named privileges
(priv.h). This project idea is to create a new privilege model,
similar perhaps to POSIX.1e or the Solaris privilege model,
allowing masks of privileges to be associated with process
credentials and managed with system calls. Of particular
interest is supporting the assignment of privileges to users or
roles -- such as the right to bind low port numbers, use DTrace,
etc.
</p>
</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&aacute;bor K&ouml;vesd&aacute;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. Alternatively, OpenBSD's
<a href="http://mdocml.bsd.lv/">mdocml</a> can replace groff's mdoc
functionality and may be sufficient 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="soc2009">
<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">
<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 versatile.</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/">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>In 2008, 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></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 &lt;machine/some.h&gt; 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>
<idea id="jailinit" class="soc">
<title>Jail init and management</title>
<desc>
<p><strong>Technical contact</strong>: <a
href="mailto:bz@FreeBSD.org">Bjoern Zeeb</a>, <a
href="mailto:imp@FreeBSD.org">Warner Losh</a>, <a
href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
<p>FreeBSD's jail(8) facility provides lightweight operating system
virtualization; with the addition of experimental virtual network
stacks, ISPs are able to efficiently host thousands of FreeBSD
instances on a single machine. This task improves FreeBSD's
userspace management of jails by introducing jailinit(8), an
enhancement to the init(8) utility responsible for starting up and
shutting down the operating system. Currently, jails are started
by executing their /etc/rc script directly using jail(8); in the
proposed new world order, init(8) would have a jail start mode,
and would continue running throughout the lifetime of the jail to
manage services and eventually shut down the jail. This might
require minor kernel changes in order to let jailinit perform some
of the same functions for jails as it does for normal userspace.
jailinit could also be responsible for setting up and managing
console logging, launching tty-attached services such as getty
within a jail, and other jail properties.</p>
<p><strong>Requirements</strong></p>
<ul>
<li>C and shell programming skills</li>
<li>Interest in virtualization</li>
</ul>
</desc>
</idea>
</category>
</ideas>
Reference in a new issue View git blame Copy permalink