Subject: Google Summer of Code project ideas
To: None <email@example.com>
From: Jan Schaumann <firstname.lastname@example.org>
Date: 04/21/2006 12:05:05
Content-Type: text/plain; charset=us-ascii
As you are probably aware, the NetBSD project will once again participate
in the Google Summer of Code 2006. We are currently compiling a list of
possible projects, but seeing how our userbase communicates primarily via
our mailing lists, I thought I should bring your attention to these
If you are interested in participating in the Summer of Code as as
student, it would be best if you would start discussing your proposal on
this list. You also want to take a look at
http://www.netbsd.org/contrib/soc-application.html for a list of questions
you should be able to answer in your application.
The projects relating to topics on this mailing list are:
* Improve Caching -- Replace all of the knobs and wacky algorithms for
sizing the many separate LRU caches in our kernel (for pages and for
various kinds of objects like metadata buffers, mbufs, etc.) with a
generalized (N-way) algorithm like IBM's ARC ("Adaptive Replacement
Cache") to size all the caches for optimal hit rate.
* Improve writing to FS -- Apply TCP-like flow control to processes
writing to the filesystem (put them to sleep when there is
"congestion"), to avoid enormous backlogs and provide more fair
allocation of disk bandwidth.
* Real time support -- Support realtime signals and process scheduling
according to POSIX standards.
* Updated Atheros WIFI support -- he latest Linux code in madwifi-ng
includes a major code overhaul and support for advanced features
(SuperAG @ 108Mbps, eXtended Range) available in these parts. It
would be nice to have these features in NetBSD, under a BSD license.
* More intelligent buffer queue management -- NetBSD has a fixed,
kernel-wide upper limit on transfer size, which is currently set to
64k on most port. This is too small to have good performances on
modern IDE and SCSI hardware; on the other hand some devices can't do
more than 64k, and in some case are even limited to less (the Xen
virtual block device for example). Software RAID will also cause
requests to be split in multiple smaller requests.
NetBSD would greatly benefit from a more intelligent buffer queue
management between the block device drivers and the higher levels (the
framework here currently only applies some selectable algorithm to sort
the queue). This framework should be able to split buffers too large for
a device into smaller ones, or aggregate multiple contiguous requests
into a larger one. This will most probably require change to at last
some block device drivers.=20
* LED/LCD Generic API -- Design and implement a general API for control
of LED and LCD type devices on NetBSD. The API would allow devices to
register individual LED and LCD devices, along with a set of
capabilities for each one. Devices that wish to display status via an
LED/LCD would also register themselves as an event provider. A
userland program would control the wiring of each event provider, to
each output indicator. The API would need to encompass all types of
LCD displays, such as 3 segment LCDs, 7 segment alphanumerics, and
simple on/off state LED's. A simple example is a keyboard LED, which
is an output indicator, and the caps-lock key being pressed, which is
an event provider.
* Simplify FFS -- Remove the residual geometry code and datastructures
from FFS (keep some kind of ?allocation groups? but without most of
what cylinder groups now have) and replace blocks and fragments with
extents, yielding a much simpler filesystem well suited for modern
disks. The result would be useful to many operating systems beyond
just NetBSD, since UFS/FFS is used in so many different kernels.
* Add Extended Attributes to FFS -- Subfiles (also called Extended
Attributes) are important for supporting the NT file model and will
enhance Samba support. They are also important for NFSv4 (called
Named Attributes) and are already supported by Sun Microsystems,
Network Appliance, and EMC.
For a detailed project description see
* Journaling for FFS -- Solaris UFS (the same filesystem we call FFS)
provides for a journaling filesystem with snapshots. Extend FFS/FFS2
similarly; it may even be possible to use a compatible on-disk
* Improve/Extend Filesystem Resizer -- The NetBSD source tree contains
the resize_ffs tool, which allows users to grow or shrink
filesystems. This tool needs a regression test suite, general code
review, stability improvements and could be ported to FFS2 etc.
* Defragmentation for FFS -- Heavily used filesystems tend to spread
the blocks all over the disk, especially if free space is scarce.
Traditionally dump/restore have been used to recreate the filesystem,
but this is not acceptable for current disk sizes. Since resize_ffs
has to relocate blocks during shrinking anyway, it should be possible
to extend it to full reordering and defragmentation.
* Port of the NVIDIA graphics driver -- Port the FreeBSD driver for
NVIDIA graphic adapter distributed by NVIDIA. Most of the work
happens in the kernel, but making the userland part work with
XFree86/X.Org and Linux binary emulation is needed too.
The complete list of project ideas is available online at
P.S.: Discussions (and implementations) of any of these projects is of
course welcome regardless of whether or not you are a student or intend
to apply for the SoC. :-)
Information wants to be free.
Information wants to be useful.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)
-----END PGP SIGNATURE-----