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
ht
tp://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.
* Teredo: Tunneling IPv6 over UDP through NATs
See http://www.ietf.o
rg/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!
* 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.
* 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.
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.
The complete list of project ideas is available online at
http://ww
w.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. 
--
A common mistake that people make when trying to design
something completely
foolproof is to underestimate the ingenuity of complete
fools.
|