Subject: Google Summer of Code project ideas
To: None <email@example.com>
From: Jan Schaumann <firstname.lastname@example.org>
Date: 04/21/2006 11:53:34
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
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,
* Teredo: Tunneling IPv6 over UDP through NATs
* 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
* 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
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. :-)
A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)
-----END PGP SIGNATURE-----