Subject: Google Summer of Code project ideas
To: None <tech-net@netbsd.org>
From: Jan Schaumann <jschauma@netmeister.org>
List: tech-net
Date: 04/21/2006 11:53:34
--6zdv2QT/q3FMhpsV
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 here as well.

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:

*  Write a WiFi browser  -- Create an easy to use wifi setup widget for
   NetBSD: browse and select networks in the vicinity by SSID, BSSID,
   channel, etc.=20

*  Teredo: Tunneling IPv6 over UDP through NATs
   See http://www.ietf.org/rfc/rfc4380.txt

*  Policy routing -- Implement the ability to route based on properties
   like QoS label, source address, etc.

*  Cleanup routing code --  Write tests for the routing code and
   re-factor. Use more and better-named variables.  PCBs and other
   structures are sprinkled with route caches (struct route). Sometimes
   they do not get updated when they should. It's necessary to modify
   rtalloc(), at least. Fix that. Note XXX in rtalloc(); this may mark a
   potential memory leak!=20

*  Extend accelerated IPsec code for IPv6; remove old IPsec code
   We currently have two complete IPsec implementations in our kernel:
   the original reference implementation imported with the KAME IPv6 stack,
   and the Leffler/Stone IPsec (also known as FAST_IPSEC) which is a
   complete rewrite intended to efficiently support hardware accelerators.
   This is a serious maintenance headache.

   The only reason the KAME IPsec remains in our tree is that the
   Leffler/Stone IPsec does not support IPv6. This should be fixed, and the
   old IPsec implementation should be removed from the kernel.

   This project would be of major benefit not only to NetBSD, but also to
   FreeBSD and to other kernels that use the KAME IPv6 and the
   Leffler/Stone accelerated IPsec. There is not really any stable,
   high-performance, hardware-accelerated, open-source IPsec with IPv6
   support; this would provide one such.=20

*  Implement IPv6 ipflow_fastforward -- Write an IPv6 counterpart to
   ipflow_fastforward in IPv4.

*  Multicast DNS -- Add multicast DNS support to NetBSD. This would add
   another keyword to nsswitch.conf (mdns) and would only be valid for
   hosts.

*  Userland daemon for the in-kernel PPPoE server --  NetBSD has a high
   performance PPPoE implementation (both client and server side), which
   runs completely inside the kernel. While this is fine for client
   installations, it is not practical for real server use.

   To solve this, a small and simple kernel modification is needed to allow
   a userland daemon to handle the early parts of a PPPoE session, until
   IPCP and/or IPv6CP are up - and then pass the complete session on to the
   kernel. A userland daemon needs to be implemented (or adapted), which
   should offer radius support.=20

   A potential extension of this project would be to improve the kernel
   handling of PPPoE sessions for multiple active sessions. The current
   design relies on only very few sessions existing (resp. pppoe device
   instances being configured) - and will need a review once a real server
   could be implemented.

*  Evaluate, benchmark and optimize samba file server performance
   Samba, the SMB file server, runs fine on NetBSD as is. Since this is
   a very common network filesharing protocol, performance of the server
   should be optimized.

   It is probably not necessary to go all the way the NFS server code did
   (i.e. move most protocol handling inside the kernel).

   This project is about evaluating possible improvements (use of kqueue,
   splice/sendfile and similar concepts, adding case independent mount
   options for the underlying filesystem - probably more to be found during
   the project), exploring possible implementations, and benchmarking.=20


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
A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools.

--6zdv2QT/q3FMhpsV
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFESP/+fFtkr68iakwRAjHdAKCoXmfwUVOYDmgKfK+Ee/Lf+asicwCfTyLC
oR+4gbXo65FWN1aQFZhvYME=
=YZDs
-----END PGP SIGNATURE-----

--6zdv2QT/q3FMhpsV--