Max Laier <[EMAIL PROTECTED]> wrote:
On Friday 04 November 2005 10:47, Robert Watson wrote:
On Thu, 3 Nov 2005, M. Warner Losh wrote:
> : Also, is there a page with other tasks for kernel neophytes like me? I
> : looked for some such page but I couldn't find any.
>
> phk used to have a /jkh/ page, or Junior Kernel Hacker page. Don't know
> if that's still that way or not.
Now that we have a FreeBSD Developer wiki, it may make sense to move the
page there so it can be more easily reached and maintained by a broader
set of developers?
http://www.freebsd.org/news/status/report-mar-2005-june-2005.html#TODO-list-for-volunteers
Not sure what the current status of the above is ...
A version of the TODO list for volunteers is scheduled to be
reviewed/reformatted by brueffer after 6.0-RELEASE (and I already have
several things I want to add to it after it's reviewed). I don't think he
will mind if someone else with doc-Fu is willing to pull this item from his
TODO list.
My intend is to make the page available parallel to the SoC page, so every
committer can modify it. I didn't do the work in the wiki, since the wiki
has some kind of test-status. The wiki is also not visible from
www.freebsd.org (linking to the wiki from internal/developer.html doesn't
count here in my eyes), so listing nice TODO items there isn't the way to go
for something which is suppoosed to lure people into producing shiny
features.
I've attached the version which is available to brueffer for review (the
other items I want to add are spread as "idea snippets" over my mailbox
folders somewhere). If someone is willing to take one of the items, the
"Port DragonFly's IP checksum code" is done and will be committet (RSN, I
think).
Bye,
Alexander.
--
http://www.Leidinger.net/ Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org/ netchild @ FreeBSD.org : PGP ID = 72077137
Ignorance is bliss.
-- Thomas Gray
Fortune updates the great quotes, #42:
BLISS is ignorance.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "FreeBSD list of projects for volunteers">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../developers.sgml"> %developers;
]>
<html>
&header;
<ul>
<li><a href="#ideas">Project Ideas</a>
<ul>
<li><a href="#p-userland">Userland / Installation Tools</a></li>
<li><a href="#p-filesystem">Filesystem</a></li>
<li><a href="#p-networking">Networking</a></li>
<li><a href="#p-security">Security</a></li>
<li><a href="#p-kernel">Kernel</a></li>
</ul>
</li>
<li><a href="#mentors">Possible Mentors</a></li>
</ul>
<a name="ideas"></a>
<h2>Project Ideas</h2>
<a name="p-userland"></a>
<h3>Userland / Installation Tools</h3>
<ul>
<li><p>
<strong>Small sysinstall renovation</strong>:
<ul>
<li>Ask for country & keyboard layout at start - so intl keyboards
work correctly.</li>
<li>Ask for network config before install - so you don't have to config
the net twice.</li>
<li>Get hostname from dhcp server too.</li>
<li>Make a guess of the timezone based upon country & keyboard.</li>
<li>Write the FreeBSD version at the top of the dispaly (or somewhere
similar visible) - so lazy users know what they are
installing (version: release, stable, snapshot + arch: i386, amd64, etc) even
when the CD is unlabeled.</li>
<li>Other usability improvements not yet thought of.</li>
</ul>
<p>
<emph>Requirements</emph>:
<ul>
<li>Good C knowledge (reading and writting).</li>
<li>No fear regarding "naturally grown" code.</li>
</ul>
</p>
</li><!-- Suggested by: Martin Nilsson <[EMAIL PROTECTED]> -->
<!-- SoC
<li><strong>Integrate BSD Installer</strong>: Prepare a prototype
merge of the <a href="http://www.bsdinstaller.org/";>BSD
Installer</a> as a complete replacement for the venerable FreeBSD
sysinstall program. Enough of the groundwork has been laid out now
that someone with a few months and some background could do a lot
of good work here, especially with adequate mentoring by more
senior FreeBSD developers.</li>
-->
<li><strong>Bundled PXE Installer</strong>:
<p>It would be great to
have a bundled PXE installer. This would allow one to boot an
install server from a FreeSBIE live CDROM 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>
<emph>Requirements</emph>:
<ul>
<li>Good PXE knowledge.</li>
</ul>
</p>
</li>
<!-- SoC
<li><strong>Fully Integrated SNMP monitoring</strong>: Plugins for
our BSNMP pieces to monitor elements of system state such as load,
disk space, VM statistics, entropy, firewall rules and states,
sendmail queues and accepts/rejects, and the like. An SNMP client
that could pull and centralize the data gathering, render it,
etc. <a href="mailto:[EMAIL PROTECTED]">&a.philip;</a>, <a
href="mailto:[EMAIL PROTECTED]">&a.glebius;</a>, <a
href="mailto:[EMAIL PROTECTED]">&a.harti;</a>, and <a
href="mailto:[EMAIL PROTECTED]">&a.rwatson;</a> are
coordinating.</li>
-->
<!--
<li><strong>Integrate Xen Support</strong>: Support for the <a
href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/";>Xen virtual
machine monitor</a> is coming into FreeBSD -CURRENT, so the
installer could be updated to make it possible to setup a Xen
system with several FreeBSD nodes, etc.</li>
-->
<!-- SoC
<li><strong>Rewrite CVSup in C</strong>: <a
href="http://www.cvsup.org";>CVSup</a> is the CVS-Optimized
General-Purpose Network File Distribution System. It has been
used heavily for nearly 10 years to distribute the FreeBSD CVS
tree to mirrors around the world. CVSup was written in Modula-3
and a rewrite in C would encourage more users to improve it.
CVSup is a multi-threaded application by design so the applicant
should have at least some experience with pthreads.
Additional requested features include understanding of Subversion
fsfs repositories and Perforce depots. Currently part of the work
and research has already been completed. More information on this
project is available <a href="http://mu.org/~mux/csup.html";>here</a>.
<a href="mailto:[EMAIL PROTECTED]">&a.mux;</a> is the coordinator.</li>
-->
<li><strong>Improve our regression testing system</strong>:
<p>Nik Clayton has written a regression test infrastructure using Perl.
More of the regression tests should be made to work with libtap.
</p>
<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>
<p>
<emph>Requirements</emph>:
<ul>
<li>Good knowledge of scripting languages (perl preferred).</li>
<li>Good knowledge of software testing.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.nik;</a>
</p>
</li>
<li><strong>Tracking performance over time</strong>:
<p>One of the major
issues in a project the size of FreeBSD is monitoring changes in
performance characteristics over time. Doing this requires several
things. Those include a suite of appropriate tests, hardware to run
the tests on, a database to store results in, and software to
extract intresting results and display them. Solving the whole
problems is probably beyond the scope of one summer's work, but an
intresting subset should be managable.
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.brooks;</a>
</p>
</li>
</ul>
<a name="p-filesystem"></a>
<h3>Filesystem</h3>
<ul>
<!-- SoC
<li><strong>UFS Journaling</strong>: Add transaction journaling and
playback to the UFS filesystem. The goal is to increase the reliability
of the filesystem and greatly reduce the need for a full 'fsck' after
a crash or power loss. This is a project that deals with not only
the filesystem internals, but also the VM and buffer/cache systems,
so it is an excellent opportunity to learn about many fundamental
aspects of an operating system.<br>
Work is already in progress on this task, but more help is always
needed and welcome. Candidates should have at least a cursory
understanding of filesystem data structures (inodes, free lists,
directories) and a strong desire to learn more about such systems.
This project would be a major contribution to anyone's resume, but it
is not for the faint of heart. <a
href="mailto:[EMAIL PROTECTED]">&a.scottl;</a> is the coordinator.
</li>
-->
<li><strong>Autofs</strong>:
<p>Create the autofs filesystem from a
specification. Most of this work is done,
however kernel transport and interaction with the "amd"
automounter needs to be completed.
<p>
<emph>Requirements</emph>:
<ul>
<li>Knowledge of filesystems and network filesystems.</li>
<li>Good knowledge of C.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.alfred;</a>
</p>
</li>
<li><strong>Logical Volume Manager</strong></li>
<li><p>
<strong>Implement Magic Symlinks</strong>:
Experimental
<a href="http://www.freebsd.org/~jwd/magiclinks.tgz";>patches</a>
exist against 4-STABLE, though the DragonFly implementation using the
setvar utility should be examined (interesting files in the DragonFly CVS:
sys/kern/init_sysent.c, sys/kern/kern_varsym.c, sys/kern/syscalls.c,
sys/kern/syscalls.master, sys/kern/vfs_lookup.c, sys/sys/syscall-hide.h,
sys/sys/syscall.h, sys/sys/syscall.mk, sys/sys/sysproto.h,
sys/sys/sysunion.h, bin/varsym/varsym.1, bin/varsym/varsym.c).
<a href="mailto:[EMAIL PROTECTED]">&a.jwd;</a> can coordinate.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Some filesystem knowledge.</li>
</ul>
</p>
</li>
<li><strong>Fix the ext2fs umount problem</strong>:
<p>If an ext2fs is mounted at shutdown time no clean shutdown is
possible. The next boot has to fsck the filesystems. If the
ext2fs is umounted before the shutdown of the system, everything
is fine.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
</ul>
</p> <!-- netchild -->
</li>
<li><strong>Implement NTFS write support</strong>:
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Very good knowledge of the NTFS.</li>
</ul>
</p> <!-- netchild -->
</li>
<li><strong>Fix mdfs lockups when using non-sync operation modes</strong>:
<p>Rev. 1.115 of md.c has a discussion of the problem.
</p>
<p>
<emph>Requirements</emph>:
<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>
</p> <!-- netchild -->
</li>
</ul>
<a name="p-networking"></a>
<h3>Networking</h3>
<ul>
<li><strong>Port DragonFly's IP checksum code</strong>:
<p>Our current IP checksum code for x86 CPUs is written in assembly
language and has some flaws which prevent its use with Intels C/C++
compiler. Those flaws may soner or later result in broken code
with gcc too. Other architectures use C versions of the code.
DragonFly's IP checksum code is better suited for modern cpus and
should at least be as good as the previous code, while being more
portable. Interesting files to look at in the DragonFly CVS are
sys/netinet/in_cksum.c, sys/sys/in_cksum.h, sys/netinet/igmp.c,
sys/netinet/in.h, sys/netinet/ip_icmp.c and
sys/i386/i386/in_cksum2.s.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Maybe knowledge of at least i386 assembly language.</li>
</ul>
</p>
</li>
<li><strong>Add zeroconf (Rendezvous/Bonjour) support to FreeBSD</strong>:
<p>
<ul>
<li>Find/write a suitable zeroconf implementation.</li>
<li>Add zeroconf support to the basesystem daemons.</li>
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Modernize ISDN4BSD</strong>:
<p>
<ul>
<li>Refactor i4b to allow to implement locking.</li>
<li>Modernize the use of kernel APIs in i4b, e.g. use busspace(9).</li>
<li>Test/fix it on amd64.</li>
<li>Determine the requirements of external software like asterisk and add
missing interfaces.</li>
<li>Write/add drivers which get recommended by asterisk.</li>
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Knowledge about ISDN.</li>
<li>Knowledge about device driver APIs.<li>
<li>A good understanding of the FreeBSD locking methods.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Network Disk Device</strong>:
<p>Add the ability to
remotely access devices from one system to another. The goal is
to allow remote access to resources such as disks, sound devices,
and other miscellaneous pieces of hardware over the network.
This project would be a good resume builder, but is not for the faint of
heart.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Understanding or interest in remote procedure call systems.</li>
<li>Understanding or interest in networking (TCP/IP).</li>
<li>Interest to learn how Unix device drivers work as well as process
management.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.alfred;</a>
</p>
</li>
<li><strong>NFS Lockd (improve semantics)</strong>:
<p>
<ul>
<li>Improve the semantics of the NFS lockd in FreeBSD. Apple has made
certain
enhancements that can be leveraged in our code base.</li>
<li>Implement state recovery in the lockd.</li>
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Good knowledge of C.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.alfred;</a>
</p>
</li>
<li><strong>NFS Lockd (kernel implementation)</strong>:
<p>Moving the lockd
implementation into the kernel provides several key performance
and semantic improvements.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Good knowledge of C.</li>
<li>Good understanding of NFS.</li>
<li>Good understanding of locking.</li>
<li>Good understanding of RPC.</li>
<li>Good understanding of kernel level networking.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.alfred;</a>
</p>
</li>
<!-- SoC
<li><strong>Userland/kernel interface cleanups (net/if_var.h)</strong>:
Over <em>eight</em> years ago, the network interface headers
were split into net/if.h and net/if_var.h. The intent was for
net/if_var.h to be kernel only and net/if.h to contain public
interfaces. Today, the internal header, net/if_var.h is still
included in many userland applications. In some cases, this is
due to interfaces that are not in fact kernel internal. In other
cases, these structures are being used in conjunction with libkvm to
access kernel information directly. This project would correct both
classes of problems, primarily rewriting the netstat(1) command and
any other network related libkvm consumers to use alternate
interfaces, creating those interfaces if needed. Netstat's
coredump analysis features would likely be split into a separate
program. <a href="mailto:[EMAIL PROTECTED]">&a.brooks;</a> is
coordinating.</li>
-->
<li><strong>Web100 port to FreeBSD</strong>:
<p>The <a href="http://www.web100.org/";>Web100</a> project was created to
address the problems of TCP performance over long-fat network
pipes. They created an interesting set of tuning and monitoring
patches for Linux which enable significantly better performance
in this area. Integrating this work into FreeBSD could provide
significant benefits in terms of TCP performance in certain
environments.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Good knowledge of C.</li>
<li>The features of Web100 need to be mapped into
appropriate FreeBSD abstractions and integrated into the
system.</li>
<li>The performance impact of these changes would have
to be quantified before the changes could be introduced.</li>
<li>Good understanding of the TCP protocol.</li>
<li>Good understanding of kernel interfaces.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.brooks;</a>
</p>
</li>
<!-- SoC
<li><p><strong>ipfw2 NAT support and libalias improvement</strong>: The
native FreeBSD firewall, ipfw2, does not currently have in-kernel
NAT support, though the architecture is extensible and the basic
mechanisms for dynamic rule creation and lookup are already
present in the kernel. At the same time, userland NAT is supported
by libalias, which has been recently made into a kernel module.
The project has the following two goals:
<ul>
<li>create hooks for ipfw2 to call LibAlias</li>
<li>revise LibAlias to improve its structures, specifically:<ul>
<li>instrument, evaluate and possibly optimize basic operations
(session creation, lookup and destruction; tcp flow
reassembly);</li>
<li>provide mechanisms to register/unregister protocol handlers
instead of having to manipulate the source code;</li>
<li>make a better match of the kernel and libalias data structure
to possibly reduce the number of copies.</li>
</ul>
</li>
</ul>
<p>The above should be applicable to 5.x and -current, and
possibly 4.x as well. Applicants should be familiar with
networking issues related to NAT, and with the network stack in
the kernel. <a href="mailto:[EMAIL PROTECTED]">Luigi Rizzo</a> is
the coordinator.</p></li>
-->
</ul>
<a name="p-security"></a>
<h3>Security</h3>
<ul>
<li><strong>SecureMines</strong>:
<p>Add meta-data to the
system in order to trap intruders and provide an audit log. The
goal of this project is to create several means of marking an
event as a foreign act (such as opening a trap file) which halts
the system and provides as much information as possible,
possibilities include using extended attributes to tag such
"mines".
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Good knowledge of C.</li>
<li>Good understanding of the Unix process model.</li>
<li>Good understanding of the FreeBSD kernel.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.alfred;</a>
</p>
</li>
<!-- SoC
<li><strong>SEBSD</strong>: SEBSD is a port of NSA's SELinux FLASK/TE
security model to the FreeBSD operating system using the TrustedBSD MAC
Framework. Right now the system is highly experimental, and a great
project would be for one or more students to spend the summer taking it
from an experimental prototype to something that can be actually used.
This might include the development of policy, integration of SEBSD into
the installer components, adaptation of userland components, sample
deployments, documentation, and so on. Candiates will want some
background in access control technology, especially mandatory access
control; experience with alternative security models would be a plus, as
would a background in OS development. However, there's room for a
range of work here, and all proposals will be considered! <a
href="mailto:[EMAIL PROTECTED]">&a.rwatson;</a> is coordinating.</li>
-->
</ul>
<a name="p-kernel"></a>
<h3>Kernel</h3>
<ul>
<li><strong>Useable lock implementation with SX-semantics</strong>:
<p>
The current sx(9) implementation has several problems that make it unusable in
many areas: Might sleep (cv_wait) on the shared lock acquisition, implicit,
hardcoded priority order without starvation protection, ...
There are several handrolled lock implementations with SX-semantics in the
tree already that solve some of the problems in their specific domain: MAC,
pfil, ipfw, if_bridge, ...
<ul>
<li>Review existing uses of non-standard sx-locks.</li>
<li>Design an API useable to replace most/all of the handrolled hacks or
find
an existing API to do the same.</li>
<li>Write the actual code.</li>
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>C knowledge.</li>
<li>Knowledge about shared/exclusive locking in SMP systems.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.mlaier;</a>
</p>
</li>
<li><strong>Document as much sysctl's as possible</strong>:
<p>
The sysctl(8) utility retrieves kernel state and allows processes with
appropriate privilege to set kernel state. On request it is able to
display description lines which document the kernel state. Unfortunately
not every sysctl is documented.
<ul>
<li>Find every undocumented sysctl in the kernel.</li>
<li>Try to determine what this sysctl is for and document it.</li>
</ul>
This task is shareable with other volunteers.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
</ul>
</p>
</li> <!-- Suggested by: Glenn Dawson <[EMAIL PROTECTED]> -->
<li><strong>Document the sound subsystem</strong>:
<p>
<ul>
<li>Add sound subsystem related section 9 man-pages, so far no sound
subsystem related pages are there yet.</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";>http://people.freebsd.org/~cg/template.c</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 man-pages, ...).
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Documentation writting skills.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.netchild;</a>,
<a href="mailto:[EMAIL PROTECTED]">&a.matk;</a>
</p>
</li>
<li><strong>Syncing with the <a href="http://www.opensound.com/";>4Front
Technologies</a>
OSS v4 API</strong>:
<p>4Front Technologies will go live with an improved OSS API in the
near future and we're discussing syncing with this API at
[EMAIL PROTECTED] 4Front Technologies offered assistance. A volunteer
would have to:
<ul>
<li>Add the necessary interfaces.</li>
<li>Add appropriate code to the sound subsystem/drivers where
possible.</li>
<li>Document the work (man pages, maybe Sound subsystem chapter in
the FreeBSD Architecture Handbook, maybe extending the example
driver). This part overlaps with the Sound subsystem
documentation project. Maybe 4Front is willing to donate parts
of their documentation. Coordination regarding this is required.</li>
<li>Use the improved API in our userland programs where it is
beneficial.</li>
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>At least one supported soundcard.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.netchild;</a>
</p>
</li> <!-- netchild -->
<li><strong>Implement the necessary kernel interface for
<a href="http://www.opensound.com/";>4Front Technologies</a> ALSA
to OSS wrapper (<a
href="http://www.4front-tech.com/forum/viewtopic.php?t=296";>SALSA</a>)</strong>:
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>At least one supported soundcard.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.netchild;</a>
</p>
</li> <!-- netchild -->
<li><strong>Improve the locking of the sound system</strong>:
<p>Only parts of the sound system provide fine grained locking yet.
</p>
<p>
<emph>Requirements</emph>:
<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 locking methods.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Add High Definition Audio (HDA) support to our sound
system</strong>:
<p>
<ul>
<li>Have a look at the <a
href="http://www.intel.com/standards/hdaudio/";>specification</a>.</li>
<li>Implement HDA support.</li>
</ul>
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>HDA soundcard.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Implement a generic input device layer</strong>:
<p>The kernel is lacking a generic input device layer analog to
the Linux 'input core' layer. Having such a layer would make it
easy to write e.g. touchscreen support (&a.philip; has some work-in-progress
regarding pointer devices and touchscreen support, but not
enough time to also cover keyboard support or other generic features).
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
</ul>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.philip;</a>
</p>
</li> <!-- netchild, philip -->
<li><strong>Add locking to the CAM layer</strong>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Kowledge about SCSI.<li>
<li>A good understanding of the FreeBSD locking methods.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Implement iSCSI</strong>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Kowledge about (i)SCSI/CAM.<li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Port DragonFly's process checkpointing</strong>:
<p>Process checkpointing allows to migrate some processes to other machines
or
to let some processes "survive" a reboot (subject to some constraints).
Interesting
files in the DragonFly CVS are sys/sys/ckpt.h, sys/checkpt/* and
sys/kern/imgact_elf.c.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Evaluate and perhaps port DragonFly's optimized memcpy/bcopy/bzero
support subsystem (this includes a FPU subsystem overhault)</strong>:
<p>
Interesting files in the DragonFly CVS are sys/i386/gnu/fpemul/fpu_system.h,
sys/i386/i386/bcopy.s, sys/i386/i386/genassym.c,
sys/i386/i386/globals.s,
sys/i386/i386/machdep.c,
sys/i386/i386/math_emu.h,
sys/i386/i386/mp_machdep.c,
sys/i386/i386/pmap.c,
sys/i386/i386/support.s,
sys/i386/i386/swtch.s,
sys/i386/i386/trap.c,
sys/i386/i386/vm86bios.s,
sys/i386/i386/vm_machdep.c,
sys/i386/include/asmacros.h,
sys/i386/include/globaldata.h,
sys/i386/include/md_var.h,
sys/i386/include/npx.h,
sys/i386/include/pcb.h,
sys/i386/include/thread.h
sys/i386/isa/npx.c,
sys/i386/i386/bcopy.s and sys/i386/i386/bzero.s. A more detailed writeup
can be found <a href="http://www.leidinger.net/FreeBSD/dfly_fpu.txt.bz2";>in
this compressed file</a>. This includes a mail from Matthew Dillon with
suggestions how to do this in FreeBSD (including a small benchmark which
shows 35%-55% speed improvement for at least those benchmarks).
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>Knowledge of at least i386/MMX/XMM assembly.</li>
<li>A good understanding of the FreeBSD SMP system.</li>
<li>Roughly 6 weeks of free time.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Sync our i386 boot code with DragonFly's boot code</strong>:
<p>DragonFly invested alot 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 both implementations and
port over interesting/good parts.
</p>
<p>
<emph>Requirements</emph>:
<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>
</p>
</li> <!-- netchild -->
<li><strong>Fix the CPU usage display in top for threaded processes</strong>:
<p>The current kernel statistics do not know how to calculate the CPU usage
of threaded processes. A volunteer has to understand the current statistics
model, design a new statistics model and implement it.
</p>
<p>
<emph>Requirements</emph>:
<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 SMP system.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Implement PCI-Hotplug support</strong>
<p>
<emph>Requirements</emph>:
<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 the FreeBSD device drivers.</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Implement something similar to Solaris' dtrace</strong>
<p>
<emph>Requirements</emph>:
<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>
</p>
</li> <!-- netchild -->
<li><strong>Add amd64 native support to thee Linuxulator</strong>:
<p>FreeBSD
provides Linux binary compatibility through a Linux system call table
that is invoked when Linux ELF binaries are executed. The
implementation on amd64 machines only provides support for 32bit (x86)
executables.
<ul>
<li>Determine a way how to distinguish between 32 bit and 64 bit
applications when entering a system call.</li>
<li>Design and implement 64 bit support while keeping 32 bit
support.</li>
</ul>
This needs to be coordinated with <a href="mailto:[EMAIL PROTECTED]">
the emulation mailinglist</a>regarding the userland part of the
linuxolator.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>A good understanding of how to do a clean room
implementation of GPLed code (no copy & paste!).</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Annotate every assembler file [*.[sS]] with dwarf2 call frame
information</strong>:
<p>
A debug kernel is not able anymore to show stack traces which cross
exceptions.
This is because we do not emit any dwarf2 call frame information for any
assembler
code, since gdb switched to the dwarf2 format.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Knowledge of assembly code.</li>
<li>Knowledge of ".cfa_*" pseudo-ops to insert dwarf2 frame
descriptors.</li>
</ul>
</p>
</li> <!-- netchild: peter via arch -->
<li><strong>Update the Linuxulator</strong>:
<p>FreeBSD provides Linux
binary compatibility through a Linux system call table that is
invoked when Linux ELF binaries are executed. This implementation
should be compared with an up-to-date Linux Kernel so that
important missing syscalls can be added to ensure that all
mainstream applications continue to work on FreeBSD.
</p>
<p>
<emph>Requirements</emph>:
<ul>
<li>Ability to read and understand foreign C code.</li>
<li>Ability to write C code.</li>
<li>A good understanding of how to do a clean room
implementation of GPLed code (no copy & paste!).</li>
</ul>
</p>
</li> <!-- netchild -->
<li><strong>Implement passive cooling in ACPI thermal</strong>:
<p>The
cpufreq interface should be used to cool the processor, based on
the various _PSV settings. Also, we need to implement variable
polling intervals for thermal zones based on both the passive
settings and polling explicitly specified in the ASL.
</p>
<p>
<emph>Requirements</emph>:
<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>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.njl;</a>
and <a href="mailto:[EMAIL PROTECTED]">&a.bruno;</a>
</p>
</li>
<li><strong>Suspend to disk</strong>:
<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>
<emph>Requirements</emph>:
<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>
</p>
<p>
<emph>Willing to mentor</emph>: <a href="mailto:[EMAIL
PROTECTED]">&a.njl;</a>
and <a href="mailto:[EMAIL PROTECTED]">&a.bruno;</a>
</p>
</li>
<!-- SoC
<li><strong>Implement and profile various algorithms for
powerd(8)</strong>: 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. Requires basic C knowledge,
laptop supported by cpufreq(4) (suggest newer Pentium-M CPU), and
some statistics. <a href="mailto:[EMAIL PROTECTED]">&a.njl;</a>
and <a href="mailto:[EMAIL PROTECTED]">&a.bruno;</a> are
coordinating.</li>
-->
<!-- SoC
<li><strong>Kernel meta-language</strong>: Develop a dialect of the
C language that simplifies the task of writing kernel code.
It should include language extensions that make it
possible to write kernel code more cleanly and with less bugs. An
example of this would have language support for linked lists,
to obviate the need for messy MACROs. <a
href="mailto:[EMAIL PROTECTED]">&a.gnn;</a> and <a
href="mailto:[EMAIL PROTECTED]">&a.phk;</a> are coordinating. A Wiki
with more information is available <a
href="http://wikitest.freebsd.org/moin.cgi/K";>here</a>.</li>
-->
</ul>
<p>Additional projects may be found by browsing the <a
href="index.html">FreeBSD Development Projects</a> page (the most
prominent projects are the
<a href="acpi/index.html">FreeBSD ACPI project</a>,
<a href="c99/index.html">C99 & POSIX Conformance Project</a>,
<a href="bigdisk/index.html">Large data storage in FreeBSD</a>,
<a href="netperf/index.html">Network Performance Project</a>,
<a href="dingo/index.html">Network Cleanup and Consolidation Project</a> and
the
<a href="busdma/index.html">busdma and SMPng driver conversion Project</a>,
but
don not forget to have a look at the other projects too) or by
viewing some of the recent <a href="&base;/news/status">Developer
Status Reports</a>.</p>
<a name="mentors"></a>
<h2>Mentors</h2>
<p>If you are interested in working on a project not explicitly
mentioned above, you may want to contact one of the potential
mentors below about writing a proposal in one of the following broad
categories.</p>
<ul>
<li><strong>Networking</strong>:
<a href="mailto:[EMAIL PROTECTED]">&a.alfred;</a>,
<a href="mailto:[EMAIL PROTECTED]">&a.brooks;</a>, and
<a href="mailto:[EMAIL PROTECTED]">&a.sam;</a></li>
<li><strong>Filesystems</strong>: <a
href="mailto:[EMAIL PROTECTED]">&a.scottl;</a>, <a href="mailto:[EMAIL
PROTECTED]">&a.alfred;</a></li>
<li><strong>GEOM</strong>: <a
href="mailto:[EMAIL PROTECTED]">&a.phk;</a></li>
<li><strong>Release Engineering / Integration</strong>: <a
href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a></li>
<li><strong>TrustedBSD / Security</strong>: <a
href="mailto:[EMAIL PROTECTED]">&a.rwatson;</a></li>
<li><strong>Pluggable Disk Schedulers</strong>: <a href="mailto:[EMAIL
PROTECTED]">&a.luigi;</a>.</li>
<li><strong>ACPI</strong>: <a href="mailto:[EMAIL PROTECTED]">&a.njl;</a>
and <a href="mailto:[EMAIL PROTECTED]">&a.bruno;</a>.</li>
<li><strong>Sound</strong>: <a
href="mailto:[EMAIL PROTECTED]">&a.matk;</a>.</li>
</ul>
&footer;
</body>
</html>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
