--JBi0ZxuS5uaEhkUZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

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
projects.

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
   http://mail-index.netbsd.org/tech-kern/2006/04/15/0012.html

*  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
   format.

*  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
http://www.netbsd.org/contrib/projects.html

-Jan

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. :-)

--=20
Information wants to be free.
Information wants to be useful.

--JBi0ZxuS5uaEhkUZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFESQKxfFtkr68iakwRAoi5AJ47DXfV/P8W3wir0BPMUCy3Pc0++QCgz1aC
+rZHvewdE1pZejyRWcTrXO0=
=VeGk
-----END PGP SIGNATURE-----

--JBi0ZxuS5uaEhkUZ--