Skip to main content.

NetBSD Summer-of-Code Projects 2008

BSD daemonNetBSD participated successfully in Google's summer of code 2005, 2006 and 2007. We are proud to have been selected as a mentoring organization again in 2008!

This page contains a list of concrete suggestions for projects we would like to see applications for. Note that they vary a lot in required skills and difficulty. We hope to get applications with a broad spectrum.

If you are interested in working on any of these projects, please contact the developer and/or mailing list referenced next to each item, and possibly answer as many questions from our Project Application HowTo as possible. The interested developers will be glad to respond to you there.

In addition, you may wish to discuss your proposal on IRC -- look for us on #netbsd-code.

We encourage you to come up with your own suggestions, if you can not find a suitable project here. You can find more project ideas on the NetBSD project ideas page. These are not directly applicable to Summer-of-Code, but may serve as ideas for your own suggestions. You might find other ideas in src/doc/TODO and pkgsrc/doc/TODO.

Deadlines and directions for students' applications to the Google Summer-of-Code can be found on the Google pages.

Project Difficulty
ATA over Ethernet High
Add Subfiles to FFS Unspecified
Add a kernel API for timed power-on Low
Add hardware bridge support to bridge(4) High
Add other package format(s) to pkgsrc Low
Add support for R10k CPUs in machines like the SGI O2 High
Add support for UVC devices (USB web-cams) Medium
Binary Formats Toolkit High
Boot Images for NetBSD Appliances High
Code Commentary Lowest
Convert all remaining regression tests to ATF Medium
Convert eeprom drivers to proplib interface Low
Convert makefs to use kernel fs code High
Create a L2TP (RFC 2661) pseudo device Medium
Create a secure SASL (RFC2222) implementation Low
Create an in-kernel API for "packet classes" High
DHCP client with minimal functionality and size Lowest
DVB drivers and kernel framework Highest
Defragmentation for FFS Unspecified
Design and implement a wstablet driver Low
Eliminate the CardBus bus back-end; support ExpressCard Highest
Evaluate, benchmark and optimize samba file server performance High
FPGA & PCI & NetBSD Highest
File Systems as Network Services High
File system access utilities (generalized mtools) Low
Flash translation layer Medium
Framebuffer driver for S3 Virge and/or S3/Trio 64 Low
Framebuffer driver for old Matrox cards Low
Framebuffer support for libsa Medium
Graceful USB disk detach/reattach High
HURD translators High
IMAPfs for mail Highest
ISDN NT support and Asterisk integration Medium
Implement Ext3 file system support Medium
Improve support for Ext2 root file system Low
Improve syslogd High
Improve the SGI bootloader Unspecified
Improve/Extend file system resizer Medium
Improving RAIDframe parity check after unclean shutdown Medium
Installable cache control (or scheduling policies) High
JTAG Kit and Guide Medium
Job migration/reconnection Highest
Job support for ps(1) Lowest
Kernel-level Cyclone Medium
LED/LCD Generic API Medium
Light weight precision user level time reading Low
MMU machine descriptions Highest
Man page indexing Low
Man page markup and formatting Low
Miniaturize NetBSD Medium
Multicast DNS Unspecified
NAND Flash device driver High
NDMP Support Medium
NVRAM buffers Medium
Nameserver configuration management Medium
NetBSD port of Qtopia Core Open Source Edition Unspecified
New LPR/LPD for NetBSD Lowest
Package update tool similar to apt-get/yum Medium
Physical address-space manager Highest
Port NetBSD to SGI Octane and Origin machines Unspecified
Port OpenAFS client support to NetBSD High
Recoverable ramdisk Low
Redundant Arrays of Inexpensive Backups Medium
SMP support for prep High
Save and restore PF filter state Medium
Secure-PLT - supporting new PLT formats on alpha or powerpc Medium
Split sysinst into front and back end Medium
Support for MIPS16e ISA Unspecified
Support for managing /etc files with rsync Low
System log monitoring Lowest
Text indexing High
Unified isabeep driver Low
Userland daemon for the in-kernel PPPoE server Low
WiFi Packet Visualizer Medium
XML utilities High
XML viewer Low
Zeroconf Unspecified
makefs enhancements Low
wcc(1) Low

ATA over Ethernet

Project summary:

AoE is a lightweight alternative to the complex iSCSI, albeit with little security, and limited to the local LAN. NetBSD can be used as an AoE target via aoe-vblade from pkgsrc, but an initiator is needed to retrieve the data from the target. This project is to create an initiator in the NetBSD kernel. The stretch goal is to provide a BSD-licensed (userland) AoE target as well.

Add Subfiles to FFS

Project summary:

Subfiles 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 this post to tech-kern.

Add a kernel API for timed power-on

Project summary:

Certain real time chips, and other related power hardware, have a facility within them to allow the kernel to set a specific time and date at which time the machine will power itself on. One such chip is the DS1685 RTC. A kernel API should be developed to allow such devices to have a power-on-time set from userland. Additionally, the API should be made available through a userland program, or added to an existing utility, such as halt(8).

It may also be useful to make this a more generic interface, to allow for configuring other devices, such as Wake-On-Lan ethernet chips, to turn them on/off, set them up, etc.

Add hardware bridge support to bridge(4)

Project summary:

bridge(4) is a software implementation of an ethernet bridge. It copies packets from each member interface to one or more of the other member interfaces. In order to do this, it puts each member interface into promiscuous mode, inspects each received packet's ethernet header to determine its destination port, and retransmits each packet. This entails a lot of CPU overhead, especially at high packet rates.

NetBSD runs on the Infineon ADM5120, a MIPS system on a chip that has a built-in, 6-port ethernet switch. The host processor controls a matrix of interconnections between ports that lets it either isolate each port, or connect it with up to five of its neighbors and the CPU to form a virtual LAN. bridge(4) could exploit this matrix to offload a lot of its work from the CPU to the ADM5120's built-in switch.

Design an interface between bridge(4) and its member interfaces for the bridge to tell each interface about the bridge's membership and configuration, so that each driver can offload the bridge's work to hardware. Extend admsw(4) to use the ADM5120's switch.

Add other package format(s) to pkgsrc

Project summary:

In 2006 and 2007, the pkgsrc build system was abstracted to allow packaging for other package system packages. For details see pkgsrc/mk/flavor/README and the original commit message

This means pkgsrc build infrastructure may be used to potentially create packages that may be installed using a non-NetBSD packaging tools (i.e. not using NetBSD's pkg_add). Note: this is not about cross-builds; the packages may be built on appropriate host system using pkgsrc collection.

This project may include creating shell command wrappers to mimic pkgsrc build needs as documented in README. (The wrappers only needed for building packages and not for using packages.) Also the project may include implementing package-specific make targets as documented in README. Also see suggestions to do in the initial commit message.

The goals of this project include:

  • Add support for RPM, dpkg, SVR4, PC-BSD PBI, and/or the Solaris native package system(s).

  • Be able to build at least 100 packages and demonstrate that the packages can be installed and deinstalled using the corresponding system's native package tools.

  • Document support and interaction with existing packages.

Add support for R10k CPUs in machines like the SGI O2

Project summary:

NetBSD/sgimips currently boots on O2s with R10k (or similar) CPUs, but crashes, as soon as a DMA transfer happens. Furthermore, speculative loads are not handled correctly. This should be fixed in the kernel (not the toolchain).

See also NetBSD/sgimips.

Add support for UVC devices (USB web-cams)

Project summary:

Most modern web cams and other video devices with USB connections are based on the UVC device class (it is a requirement for Vista certification).

This project should create kernel drivers for this device class. Defining the exact userland API, and porting at least one existing application to it is also part of this project.

There are UVC drivers for OpenSolaris which, in common with Linux, use Video4Linux 2 (v4l2) as the API. This has good application support, but this does not mean it is mandatory. However, a subset of v4l2 as appropriate for the devices being supported by this project may be worthwhile.

Binary Formats Toolkit

Project summary:

Write a netpbm-style toolkit for converting and processing binary/executable formats. Since a complete such toolkit is a large project, the first step should be to identify a useful set of tools to start out with.

This project could be a bottomless pit, out of scope for a summer of code. If you write a proposal, feel free to limit the range - but keep the big picture in mind!

Note: evaluate FreeBSD's libelf for elf file format support.

Boot Images for NetBSD Appliances

Project summary:

Add to build.sh the ability to build boot images for a NetBSD-based appliance such as a firewall, a file server, or a wireless router. In addition to building a NetBSD kernel and distribution, build.sh needs to:

  • Install the system to a staging area.
  • Cross-build and install 3rd-party application software.
  • Filter extraneous files from the METALOG.
  • Install groups and users.
  • Install application-specific rc.conf(5), scripts, data and configuration files.
  • Create a bootable FFS/ISO9660 image with makefs(8), disklabel(8), fdisk(8), installboot(8); a Network File System archive; or a kernel with memory-disk root.

A single specifications file should tell build.sh everything it needs to know to build an appliance boot image. Ideally, your successful completion of this project will incite development of spec files for several useful appliances!

Look closely at CUWiN's scripts for cross-building NetBSD-based boot images for a wireless “mesh” router, and borrow freely. The scripts represent more than five years' experience with cross-building NetBSD appliances, and they provide most of the above-mentioned functions. The scripts are not integrated with build.sh, however, and they do not support a spec file.

Code Commentary

Project summary:

Write a wiki-type tool to allow writing and maintaining parallel commentary on code. (That is, code on one side and commentary on the other, in the style of the old Lions book.)

It is not immediately clear how tightly integrated this should be with cvs or cvsweb. The first step in the project is to answer this question.

Convert all remaining regression tests to ATF

Project summary:

During the last summer of code, the Automatic Testing Framework has been created. Some tests from src/regress have been converted, but most of them are still left to do. The conversion difficulty ranges from very simple to moderately hard, but the tests need to be reviewed one by one to find the (upto now) undocumented constraints (like: needs to run as root, can not run as root, does not work on SMP machines etc.)

Convert eeprom drivers to proplib interface

Project summary:

4-5 different drivers currently share the eeprom(8) program, each with a slightly different ioctl interface. Because of this, each system needs its own separate code in eeprom(8), making the entire program ugly and unwieldy.

Rather, a unified interface to dealing with nvram, eeprom, and Open Firmware environment settings should be developed, preferably with proplib, and all the relevant drivers should be converted to using that. Once that is done, eeprom(8) can be rewritten to no longer require nearly as much machine dependent code.

Convert makefs to use kernel fs code

Project summary:

The makefs utility creates a file system image from a given directory tree. For ffs, it is currently implemented using specially modified kernel code to populate the file system image.

The goal of this project is to convert makefs to use vanilla kernel file system code with the help of the Runnable Userspace Meta Program framework and the ukfs library. This will reduce code duplication and will also provide the option to support any kernel file system with write support.

The project's work areas are two-faceted: they involve both the build framework and file system creation:

  • Figure out how to get librump and the relevant file system libraries compiled as part of the tool build. This involves most likely making them shared libraries, which involves figuring out how to flag ABI incompatibilities (tag the library with the kernel version?). It also involves figuring out how to install the same libraries as part of the base system.

  • Test and make sure that the resulting code runs at least on NetBSD, FreeBSD and some Linux distributions. The NetBSD kernel file system code has been run in userspace on Linux with ukfs before, but support has likely bitrotted.

  • Implement support for file system creation for at least FAT.

  • Convert ffs to use the vanilla kernel ffs code and ukfs instead of handcrafted code. Add equivalent support for at least FAT.

The project will be implemented entirely in userspace. While file system knowledge is a requirement for creating empty file systems, handling kernel file system code is not a requirement. The student should have a good understanding about the build framework.

Create a L2TP (RFC 2661) pseudo device

Project summary:

The generic Layer 2 tunnel protocol described in RFC 2661 is used in many VPN solutions. While it is possible to implement it completely in userland (and such implementations exist), for performance reasons most of the implementation should go into the kernel. This leads to a design very similar to the NetBSD in-kernel PPPoE support, which can be used as a starting point for this project.

A simple client could be done completely in kernel, but to provide a scalable server side, part of the handling should be done in userland. A daemon could establish and authenticate incoming connections, then pass them on to kernel and only become involved again when the kernel notifies the daemon of unusual events (like closing the connection).

This daemon could be extended to also deal with PPPoE, as a bonus, but this will not be required part of the project.

Create a secure SASL (RFC2222) implementation

Project summary:

RFC 2222 describes a very simple authentication mechanism that has been applied to various connection oriented protocols. One example is to authenticate MUAs with their outgoing mail server. This project should, at least, result in a library integrated with the in-tree postfix client to allow SASL based mail authentication. The primary design goal is a secure system, i.e. no postfix-user readable cleartext client password database.

Additional integration with pkgsrc would be a bonus.

Note: check dovecot and evaluate it.

Create an in-kernel API for "packet classes"

Project summary:

Create an in-kernel API for registering "packet classes" and for labeling packets with their class, for special treatment by traffic shapers (ALTQ) and by network interface drivers. With the registration part of the API, ALTQ or a driver registers the names of packet classes it recognizes. For example, ALTQ will register the 'class_name' part of a Class Command - see altq.conf(5). An Ethernet NIC with high- and low-priority transmit rings may register classes called 'hipri' and 'lopri'. An 802.11 NIC may register 802.11e traffic categories, BE, BK, VI, VO. Each registration yields a token that is suitable for labeling a packet - i.e., a small amount of data to stick in an mbuf packet header or in an m_tag.

Make PF use the packet-classes API to convert PF tag names—see pf.conf(5) for more about tags—to packet-class tokens, and to label mbufs with the tokens as they exit PF. Make ALTQ extract the packet-class tokens from mbufs and use them to select the packet-scheduling class.

DHCP client with minimal functionality and size

Project summary:

The ISC DHCP client used in NetBSD is a pretty huge application, with rich and complex configurability. This is great for complex scenarios, but not needed for many others.

Overall target is to create a good-enough DHCP client solution with the minimal possible footprint.

DVB drivers and kernel framework

Project summary:

NetBSD is lacking a framework for DVB (digital video broadcast) receivers. This project should create such a framework and deliver at least one driver for a DVB card making use of the framework.

Further userland work will be needed, for example adapting mythTV to this new kernel API, but this is not part of the project.

A major part of this project is designing the kernel subsystem. There are several alternative approaches: follow the LinuxTV model, which is now used by OpenSolaris too, or go for a solution similar to DirectShow. There also is ongoing work in FreeBSD, and of course it would be possible to develop a simple NetBSD specific API (creating slightly more work for porting existing userland applications.)

Defragmentation for FFS

Project summary:

Heavily used file systems tend to spread the blocks all over the disk, especially if free space is scarce. Traditionally dump/restore have been used to recreate the file system, 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.

Design and implement a wstablet driver

Project summary:

There is no equivalent to the wsmouse (for mice) or wskbd (for keyboards) subsystem for graphics tablets in the generic wscons console driver framework that most NetBSD ports use. Designing and documenting the API, as well as creating at least one hardware driver and interfacing to the X server is the objective of this project.

Eliminate the CardBus bus back-end; support ExpressCard

Project summary:

CardBus is essentially a hotpluggable PCI bus in a compact form-factor, but in NetBSD, there are independent CardBus and PCI bus back-ends. The back-ends replicate a lot of code, and many drivers have very similar bus front-ends both for PCI and for CardBus. Introduce both dynamic management of PCI bus resources (memory and I/O address space, interrupts) and insertion/ejection-event handling to the PCI bus back-end. Use the PCI bus back-end to replace the CardBus back-end. If time allows, use your PCI bus back-end improvements to support ExpressCard.

Evaluate, benchmark and optimize samba file server performance

Project summary:

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 file system - probably more to be found during the project), exploring possible implementations, and benchmarking.

FPGA & PCI & NetBSD

Project summary:

  • Estimated difficulty: Highest
  • Person/group of contact: David Young

Do something useful and cool with the Dragon FPGA board. For example, demonstrate a PCI bus master that computes some useful function (encryption, signal processing, neural network) for the NetBSD host, or a PCI bus analyzer controlled by a NetBSD character device. Each component of your product, including the VHDL, should be open source.

File Systems as Network Services

Project summary:

File systems are historically mounted by specifying which type of file system is mounted from where (e.g. mount -t ffs /dev/wd0a /mnt). However, sometimes a user is only interested in making the data available and not particularly interested in how or from where it is made available.

This project investigates the first steps in turning file systems into network-transparent services by making it possible to mount any kernel file system type from any location on the network. The file system components to be used are puffs and rump. puffs is used to forward local file system requests from the kernel to userspace and rump is used to facilitate running the kernel file system in userspace as a service daemon.

The subtasks are the following:

  • Write the necessary code to be able to forward requests from one source to another. This involves most likely reworking a bit of the libpuffs option parsing code and creating an puffs client, say, mount_puffs to be able to forward requests from one location to another. The puffs protocol should be extended to include the necessary new features or another protocol defined.

    Proof-on-concept code for this has already been written.

  • Currently the puffs protocol used for communication between the kernel and userland is machine dependent. To facilitate forwarding the protocol to remote hosts, a machine independent version must be specified.

  • To be able to handle multiple clients, the file systems must be converted to daemons instead of being utilities. This will also, in the case of kernel file system servers, include adding locking to the communication protocol.

The end result will look something like this:

# start serving ffs from /dev/wd0a on port 12675
onehost> ffs_serv -p 12675 /dev/wd0a
# start serving cd9660 from /dev/cd0a on port 12676
onehost> cd9660_serv -p 12675 /dev/cd0a

# meanwhile in outer space, mount anotherhost from port 12675
anotherhost> mount_puffs -t tcp onehost:12675 /mnt
anotherhost> mount
...
anotherhost:12675 on /mnt type <negotiated>
...
anotherhost> cd /mnt
anotherhost> ls
  ... etc

The student should have some familiarity with file systems and network services. The application should include an answer to the following question: "how is this different from nfs?"

File system access utilities (generalized mtools)

Project summary:

The mtools project provides command line tools for accessing FAT file system images without having to mount the file system. However, it duplicates a lot of equivalent code which already exists in a kernel file system and therefore misses out on synergy benefits, e.g. more testing for the same code.

NetBSD provides support for running kernel file system code in userland via the Runnable Userspace Meta Program functionality. By using the libukfs library, it is possible to access file system images directly in userspace without having to mount the file system image. This can be used to implement mtools-like functionality for any file system supported by the NetBSD kernel. To the best of our knowledge, functionality to be implemented in this project is not available in any mainstream OS.

The project consists of the following tasks:

  • Design and implement a set of tools for file system access. Usage examples are: rdir ffs ~/ffs.img /bin, which would list the "/bin" directory of an ffs image, rcat efs ~/efs.img /etc/passwd which would display the contents of "/etc/passwd" on an efs image, and rrmdir msdos /dev/rwd1a /nukeme would remove the directory "nukeme" from an msdosfs file system on wd1a.

  • Additionally, if there is time left, implement the same functionality as a command console similar to e.g. fsdb. Since this allows to retain state across different file system requests, it could provide extra features not possible with standalone command line tools. This and the command line utilities should either share a common backend, or the command line utilities can be implemented as a frontend to the command console.

  • Implement a test suite for regression testing of the utilities created in the project.

  • For extra credit, verify that the created utilities are buildable and work on non-NetBSD platforms. NetBSD kernel file systems have already been run in userspace on non-NetBSD platforms, so this is known to be possible.

To get an idea of how to proceed with the implementation, the very unfinished fsconsole can be studied along with the ukfs library programming interface. mtools can also be studied for inspiration.

This focal point of this project is producing tools with good usability. Even though kernel file system code will be used, this project will be implemented entirely in userspace and there is no need to understand kernel file system code.

In a very very distant future the above toolset could be integrated with standard POSIX.1 command line utilities, e.g. ls and mknod. But since this requires huge changes to e.g. how system calls are handled, how mount points are handled, and what the OS treats as a service, it is most definitely outside the scope of a SoC project. This is mentioned just to point out that there are plenty of future research opportunities for interested students familiar with the problem area.

Flash translation layer

Project summary:

Implement flash-translation layer to handle bad-block management/wear leveling such that a FFS or LFS file system could be placed on above NAND flash chip.

Framebuffer driver for S3 Virge and/or S3/Trio 64

Project summary:

Many (non i386) machines used S3 graphic cards. It is one of the cards primarily found on IBM machines. Having a frambuffer driver for those cards would allow early console initialization on those machines.

Framebuffer driver for old Matrox cards

Project summary:

Many (non i386) machines used Matrox G200 and similar graphic cards. Having a framebuffer driver for those cards would allow early console initialization on those machines.

Framebuffer support for libsa

Project summary:

On some machines (e.g. prep) the framebuffer can not be used by the bootloader, so we boot blind, until the kernel framebuffer driver initializes the hardware and starts output.

Having something genfb(4)-like plus rasop in libsa would allow a full featured bootloader on graphical console.

Graceful USB disk detach/reattach

Project summary:

Make NetBSD behave gracefully when a "live" USB/FireWire disk drive is accidentally detached and re-attached by, for example, creating a virtual block device that receives block-read/write commands on behalf of the underlying disk driver. This device will delegate reads and writes to the disk driver, but it will keep a list of commands that are "outstanding," that is, reads that the disk driver has not completed, and writes that have not "hit the platter," so to speak. Following disk re-attachment, the virtual block device replays its list of outstanding commands. A correct solution will not replay commands to the wrong disk if the removable was replaced instead of re-attached. Provide a character device for userland to read indications that a disk in use was abruptly detached.

Open questions: Prior art? Isn't this how the Amiga worked? How will this interact with mount/unmount—is there a use-count on devices? Can you leverage "wedges" in your solution? Does any/most/all removable storage indicate reliably when a block written has actually reached the medium?

HURD translators

Project summary:

The GNU project's operating system HURD is not yet exactly ready for comfortable use. However, it introduces the interesting concept of translators, which generalize the notion of "mount point".

Enabling to use HURD tranlators within NetBSD could provide added functionality for users of NetBSD as well as a stable and efficient platform for developers of HURD translators.

The project touches several aspects of the kernel:

  • File system modifications: support for settrans/showtrans in ext2fs and ufs, fsck changes to accomodate for the presence of translators

  • Virtual file system modifications: adding the concept of passive/active translator, enabling the mounting of a translator on any vnode, not just a directory

  • (Writing one very basic native translator)

  • Binary emulation of GNUMach executables to the point where a few native useful translators can be run

The last point is probably very long, but can be done progressively. The second point is strategic because it will prove the concept's validity and will guarantee the success of the project in the long run.

IMAPfs for mail

Project summary:

Use puffs or refuse to write an imapfs that you can mount on /var/mail, either by writing a new one or porting the old existing Plan 9 code that does this.

Note: there might be existing solutions, please check upfront and let us know.

ISDN NT support and Asterisk integration

Project summary:

This projects has two subprojects: add support for the NT (network) side of ISDN to the NetBSD ISDN stack and interface ISDN (in NT mode) to the Asterisk PBX, which would allow using existing ISDN PBXes as SIP/VoIP phones, as well as easier testing of new ISDN card drivers.

Previous work in this area can be found at the alternative ISDN driver site.

Implement Ext3 file system support

Project summary:

The Ext2 file system is the de-facto standard, Unix-like file system used on Linux installations. Ext2 does not have journaling capabilities, so Ext3 was built on top of it to add them without breaking compatibility with Ext2. Ext3 is now a stable journaled file system used on lots of Linux installations.

NetBSD currently fully supports the Ext2 file system at the kernel level. Unfortunately there is no support for the new features included in Ext3, although Ext3 file systems can be mounted provided that their journal is clean. It would be very nice if NetBSD had Ext3 file system support because the system could immediately gain a journaled file system as well as compatibility with Linux (imagine having both systems installed on a single partition!). This has, supposedly, lower risk than adding journaling to UFS because Ext3 is already heavily deployed and tested.

Therefore, the aim of this project is to add Ext3 support to the NetBSD kernel accompanied by any userland code required to support it. This shouldn't be too difficult because, as we already mentioned, Ext2 is implemented in the NetBSD kernel (see src/sys/ufs/ext2fs/) and Ext3 is an extension of it.

Improve support for Ext2 root file system

Project summary:

NetBSD currently has support for the Ext2 file system. Unfortunately, it has some deficiencies that make its use unsuitable for a root file system, as detailed below. (Strictly speaking it can be used as such, but it is not easy to do so.)

The Ext2 file system driver in the NetBSD kernel currently supports the use of this file system as the system's root. That is, / can live in an Ext2 partition. However, there is no way to natively boot NetBSD using this mechanism because there is no bootxx_ext2fs boot loader. Similarly there is no support in sysinst to install NetBSD directly onto a Ext2 partition. At the moment the only way to get this to work is to do a manual installation and later use GRUB to boot the kernel instead of the native boot blocks.

But why would this be interesting? Ext2 is a very popular file system. Supporting it as root would mean that you'd install NetBSD inside the same partition as Linux (with some very minor unimplemented features). Similarly, if Ext3 support is added, NetBSD would immediately gain a journaled file system to be used for any partition. Furthermore, this eases cross-development of NetBSD from Linux operating systems.

Unfortunately, there are some tricky parts in using bootxx_ext2fs even with ext2fs support in the kernel's libsa. Ext2 file systems always have their superblock stored at a 1024-byte offset from the start of the file system. This does not leave enough room to install the boot code. A workaround for this shall be found: maybe implementing bootxx_ext2fs is not really needed as long as /boot has Ext2 knowledge and its location is hardcoded in the first boot stage. (This means you will need to deal with installboot's code too.)

At last, fsck_ext2fs should be improved because, after a crash, it detects (and attempts to correct!) far more errors than its Linux counterpart. It can end up destroying some data that ought to be correct in the first place because it thinks is incorrect.

Improve syslogd

Project summary:

System logging in NetBSD (and other Unixes) has some fairly serious shortcomings. There is no authentication of message senders (that is, any user can spoof just about any system message), no particular guarantees that messages do not get lost, and no facility for rate-limiting or otherwise preventing intentional denial-of-service. Other drawbacks can probably be identified by comparing syslogd.c with government/military requirements for logging and auditing in secure systems.

The project is to, first, analyze the problem thoroughly: determine what is lacking, which of these issues can reasonably be corrected, and what system-level or kernel-level infrastructure will be required to make these corrections; then, to implement a reasonable subset of the desired corrections and provide the documentation and analysis necessary for others to undertake the remainder.

Improve the SGI bootloader

Project summary:

Currently booting a sgimips machine requires different boot commands depending on the architecture. It is not possible to use the firmware menu to boot from CD.

An improved primary bootstrap should ask the firmware for architecture detail, and automatically boot the correct kernel for the current architecture by default.

Improve/Extend file system resizer

Project summary:

The NetBSD source tree contains the resize_ffs tool, which allows users to grow or shrink file systems. This tool needs a regression test suite, general code review, stability improvements and could be ported to FFS2 etc.

Optional items include making it work on FFS2 file systems, or on live file systems

Improving RAIDframe parity check after unclean shutdown

Project summary:

NetBSD's RAIDframe disk driver raid(4) currently checks the parity of a complete RAID set after an unclean shutdown. This can take several hours in case of RAID sets which span hundreds of gigabytes and will cause high I/O load on the system during that period.

The cause of this problem is that RAIDframe currently uses a single bit to indicate whether or not a given RAID sets parity is known to be up-to date. On an unclean shutdown, this bit indicates that the status of the RAID set is DIRTY and that a complete check of all parity on the RAID set must be done.

Similar RAID drivers for other operating systems implement a more efficient strategy for rewriting the parity. Solaris Volume Manager e.g. divides the disk into logical sections and keeps track which of these sections are out of sync. After an unclean shutdown it only rewrites the parity for all sections which are marked as out of sync.

The purpose of this project is to implement a solution which reduces the amount of time required to check parity after an unclean shutdown.

Installable cache control (or scheduling policies)

Project summary:

The policy code in the kernel that controls file caching and readahead behavior is necessarily one-size-fits-all, and the knobs available to applications to tune it, like madvise() and posix_fadvise(), are fairly blunt hammers. Furthermore, it has been shown that the overhead from user<->kernel domain crossings makes syscall-driven fine-grained policy control ineffective.

Is it possible to create a BPF-like tool (that is, a small code generator with very simple and very clear safety properties) to allow safe in-kernel fine-grained policy control?

Caution: this is a research project.

JTAG Kit and Guide

Project summary:

Produce lessons and a list of affordable parts and free software that NetBSD hobbyists can use to teach themselves JTAG. Write your lessons for a low-cost embedded system or expansion board that NetBSD already supports.

Job migration/reconnection

Project summary:

Figure out how to move jobs (in the job control sense) between ttys, or reconnect to your jobs after getting hung up on.

This requires a fairly substantial understanding of how job control and sessions work in Unix and would probably require hacking both the tty driver and one or more shells.

Job support for ps(1)

Project summary:

Extend ps to have a mode that displays jobs (at the job control level) and rolls their component processes together, much as how threads within a process are rolled together by default.

Kernel-level Cyclone

Project summary:

Figure out what infrastructure is necessary for writing kernel components (particularly device drivers) in Cyclone. Implement it, or determine that it is not feasible, and if not, identify what the problems are and how they might be solved.

LED/LCD Generic API

Project summary:

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.

Light weight precision user level time reading

Project summary:

Design and implement a mechanism that allows for fast user level access to kernel time data structures for NetBSD. For certain types of small data structures the system call overhead is significant. This is especially true for frequently invoked system calls like clock_gettime(), time(), gettimeofday(). With the availability of user level readable high frequency counters it is possible to create fast implementations for precision time reading. Optimizing clock_gettime and alike will reduce the strain from applications frequently calling these system calls and improves timing information quality for applications like NTP. The implementation would be based on a to be modified version of the timecounters implementation in NetBSD.

See also the Paper on Timecounters by Poul-Henning Kamp.

MMU machine descriptions

Project summary:

The number of pmap modules in the system is large, and most of them are substantially similar. This leads to the usual systemic ills that arise from cut and pasted code: bugs are often shared, bug fixes often don't propagate, and so forth.

It should be possible to generate each pmap.c from a template and a machine description, given a suitable MMU-oriented machine description language. The project is to design and build the necessary materials.

Caution: this is a research project.

Man page indexing

Project summary:

Implement real full-text search for man pages, to replace the dated and nearly useless mechanism implemented in makewhatis(8).

Man page markup and formatting

Project summary:

Put together an XML format equivalent to -mdoc, then write a bidirectional converter for man pages and a nice text-mode man browser.

Miniaturize NetBSD

Project summary:

  • Estimated difficulty: Medium
  • Person/group of contact: David Young

Produce a boot image for a system with no more than 4MB Flash / 16MB RAM, run a useful NetBSD router with DHCP client/server, IPv6 route solicitation/advertisement, PPPoE, and an 802.11a/b/g WPA access point. Your image must be replicable: using only the NetBSD sources, the 3rd-party sources you select, and your scripts and Makefiles, a developer should be able to cross-build your system boot image.

Multicast DNS

Project summary:

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

See also http://www.multicastdns.org/.

NAND Flash device driver

Project summary:

Write a block device driver the NAND Flash on a low-cost embedded board that NetBSD supports—e.g., RouterBOARD 153. Show that you can erase blocks on the flash, write NetBSD to the flash, and boot NetBSD with root on flash. When you finish your first driver, write a driver for a second NAND part, and extract common code for reuse in the driver after that.

NDMP Support

Project summary:

The NDMP protocol specifies the protocols to perform dumps and backups across a network. There are a number of BSD-licensed XDR specs for NDMPv4, and this project is to provide the necessary functionality to take the RPC invocations and perform the work to save and present the data across the network. This backend to the NDMP protocol will allow NetBSD to act as an NDMP server for communication with third-party applications, such as Netbackup.

NVRAM buffers

Project summary:

Add support for using a non-volatile RAM card as a buffer for the journal of a journalled file system, so the journal can be written less often and in larger chunks.

Nameserver configuration management

Project summary:

Right now, if you change nameservers by editing resolv.conf, you have to kill and restart all running programs to get them to stop using the old nameserver.

Figure out a clean and scalable way to get changes to resolv.conf to propagate to running processes.

NetBSD port of Qtopia Core Open Source Edition

Project summary:

Qtopia Core (formerly QT/Embedded) is a framework for building single-application devices on embedded systems. Currently this only runs on Linux, but many current and future NetBSD systems would benefit from having a light-weight replacement for X11 provided by Qtopia Core.

See also the Qtopia Core Open Source download.

New LPR/LPD for NetBSD

Project summary:

The current lpr/lpd system in NetBSD is ancient, buggy, and doesn't support modern printer systems very well. Interested parties would do a from scratch rewrite of a new, modular lpr/lpd system that would support both the old lpd protocol and newer, more modern protocols like IPP, and would be able to handle modern printers easily.

Package update tool similar to apt-get/yum

Project summary:

pkgsrc currently has a set of tools, known as pkg_install, to install, remove and overall maintain the packages installed in a system. Unfortunately, there is no tool to do automated and safe updates of all the installed packages so, generally, this boils down to deinstalling everything in the machine to later install the new versions. As you can imagine, this is unacceptable for production machines or even desktop systems, specially if you are installing from source packages. Doing such updates from binary packages alone is slightly tolerable because they can be made quickly enough (once the binaries are already available). It is clear that we need a tool to do massive updates on a running system with minimum downtime.

Recently, we added package databases to our binary repositories, as described in pkg_summary(5). These databases will make writing an update tool way easier than would be without them.

The aim of this project is to provide a tool that:

  • Retrieves one or more pkg_summary databases.

  • Compares what is installed with what is available.

  • Updates or installs new packages as deduced in the previous stage.

The tool will have to check for conflicts and also library compatibilities when making a decision; note that this information is already available. The tool can be interactive to list what will be done and prompt user to acknowledge, but should allow automation too. The tool should also be able to just indicate what can be updated, download packages only, and search the databases.

Ideally, such a tool could work both from binary and source packages, allowing the user to tune which ones to use. This could make the tool useful for all systems that do not have up-to-date binary packages available, such as slow platforms or non-NetBSD systems (as pkgsrc sees much less use on them). However, this is harder to achieve safely due to all problems that can arise when building software from sources. Therefore, the tool need not support this by the end of the SoC project, but it should be correctly designed to allow future extensions in this direction.

At last, let us note that there was a pkg_install rewrite in process. The new tools have a library ready to be used from C code to handle packages. Depending on its status by the time when the project is started, the update tool might need to be built on top of this library for better integration with the new tools or simply to simplify its coding. If this is not desired at that time, it should be built around the current tools.

An excellent starting point to carry on with would be the pkg_select utility that can be found in pkgsrc-wip/pkg_select, as it has lots of the requested features, but needs some cleanup.

Alternatively, one may attempt to port one of the existing tools for other systems (apt-get, yum, urpmi or synaptic to mention some) and make them work with pkgsrc packages through the use of pkg_summary. The downside of this approach is that the tool could not be included in NetBSD because it would not be BSD licensed.

Physical address-space manager

Project summary:

Replace the machine-dependent, ad-hoc mechanisms for allocating physical address space in NetBSD with a machine-independent address-space manager.

Port NetBSD to SGI Octane and Origin machines

Project summary:

NetBSD/sgimips currently runs on a number of SGI hardware, but support for IP27 (Origin) and IP30 (Octane) is not yet available. An Octane for development is available for pickup in Hoboken, NJ (contact Jan Schaumann ).

See also NetBSD/sgimips.

Port OpenAFS client support to NetBSD

Project summary:

OpenAFS currently exists in pkgsrc for the server portion. Client support would require fixing the legacy NetBSD client support. Updates would need to either make use of the new LKM interface or possibly PUFFS.

Recoverable ramdisk

Project summary:

Laptops tend to not have power failures and some at least don't clear memory on reboot; can one build a ramdisk that survives reboot?

Redundant Arrays of Inexpensive Backups

Project summary:

Build a backup system using erasure coding or some such foo on DVDs, so you can just add more discs over time, you only need some (smaller) number of them to restore, and so on, with the various parameters adjustable.

Note: there might be existing solutions, please check upfront and let us know.

SMP support for prep

Project summary:

Add support for SMP to port prep.

This project requires access to the necessary hardware (7025-F40 or MTX604)

Save and restore PF filter state

Project summary:

Make it possible to save and restore the state of the PF packet filter to disk. The function desired is similar to ipfs(8), however, we would like the saved state to be in a human-readable form. In particular, write the PF NAT & firewall state in the format of PF rules. You will need to augment the PF rules syntax so that it can express properties of PF state such as its TTL. You need to produce a kernel interface for loading the state, and make pfctl's parser understand it. You need to make changes to the in-kernel parts of PF in order to load state. Also, provide for locking/unlocking the PF state tables as they are loaded/dumped.

Secure-PLT - supporting new PLT formats on alpha or powerpc

Project summary:

Currently kernels with options PAX_MPROTECT can not execute dynamically linked binaries on most RISC architectures, because the PLT format defined by the ABI of these architectures uses self-modifying code.

New binutils versions have introduced a different PLT format (enabled with --secureplt) for alpha and powerpc.

These two projects (one for alpha, one for powerpc) are to add support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files.

Support for both the old and new formats in the same invocation will be required.

Split sysinst into front and back end

Project summary:

Sysinst is the current installer for NetBSD. Currently, the installer is an interactive process, where it asks you questions, and acts immediately on those answers.

Sysinst should instead be broken into two components. A front end, which asks a number of questions about the install, such as disk layout, machine name, etc, and a back end, which does the actual installation. The front end, should create an installation configuration file, which would describe the installation to be performed to the back end. This configuration file should be flexible enough, that it can be hand-edited to contain things such as "swap should be 10% of the disk, or at least 128MB". In this way, a default configuration could be shipped, which would allow the user to simply bypass the front end, and run the back end.

The back end would do all the actual work of the installation, taking its cues from the description file. With a flexible enough configuration file, it would be possible to build a kickstart/jumpstart like system by supplying config files and executing them via the backend.

Support for MIPS16e ISA

Project summary:

NetBSD currently supports the MIPS32 ISA, but does not include support for the MIPS16e extension, which would be very useful for reducing the size of binaries for some kinds of embedded systems. This is very much like the ARM thumb instructions.

Support for managing /etc files with rsync

Project summary:

NIS is messy and insecure and unacceptable or problematic in many environments. While LDAP may be a possible alternative, in many cases a simple and tidy solution is to distribute configuration from a central machine using rdist, rsync, or a distributed change management system such as Mercurial, Git, or Monotone.

Attempting to distribute all of /etc this way is problematic; in general it is better to set up a subdirectory that contains only the files that are meant to be distributed.

The project is to extend libc's nsswitch mechanism to support an additional configuration source, "distfiles" (or some similar name), which reads the associated files (in the standard format) from /etc/distfiles (or some similar name), so that the latter directory can be managed with rsync and its data can be combined with regular /etc data in the same way it can when NIS is in use.

System log monitoring

Project summary:

Apply statistical AI techniques to the problem of monitoring the logs of a busy system. Can one identify events of interest to a sysadmin, or events that merit closer inspection? Failing that, can one at least identify some events as routine and provide a filtered log that excludes them? Also, can one group a collection of related messages together into a single event?

Text indexing

Project summary:

Implement full-text indexing for /home, akin to Apple's Spotlight.

Unified isabeep driver

Project summary:

Many ports have sysbeep/isabeep drivers, but there is little code sharing. This should be restructured and a single driver (maybe with machine dependent hooks) should be created.

Userland daemon for the in-kernel PPPoE server

Project summary:

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.

WiFi Packet Visualizer

Project summary:

Create an add-on for Wireshark that reads a trace of 802.11 packets with radiotap headers, and renders each packet as a trapezoid on a timeline, like this:

Place the left edge of a trapezoid to represent a packet's time of arrival. Set the length of the top or bottom edge in proportion to transmit duration. Use other display properties of the trapezoid such as shear, hue, saturation, height, texture, and top-edge width to express packet properties such as signal strength, bitrate, type (management, data, control), MAC, and BSSID.

In 2003, a student team worked on the visualizer. They did not produce a finished product, but their report on Argos may help you.

While you design and code the display add-on, keep in mind both the important 802.11 transactions, such as (RTS/CTS/)Data/Ack, and export to SVG, PDF, or PostScript for reproduction on the WWW or in print.

XML utilities

Project summary:

Produce a suite of simple command-line utilities that act on XML files as grep(1), sed(1), and join(1) act on plain text files. For example, xmlgrep(1) may select contents of an XML file by XPath-like language, regular expression, or both; it may emit either a well-formed subset of the XML input, or plaintext.

XML viewer

Project summary:

Write a good text-mode browser for random XML schemas.

Zeroconf

Project summary:

Enhance zeroconfd, the Multicast DNS daemon, that was begun in NetBSD's Google Summer of Code 2005 (see work in progress: http://netbsd-soc.sourceforge.net/projects/zeroconf/). Develop a client library that lets a process publish mDNS records and receive asynchronous notification of new mDNS records. Adapt zeroconfd to use event(3) and queue(3). Demonstrate comparable functionality to the GPL or APSL alternatives (Avahi, Howl, ...), but in a smaller storage footprint, with no dependencies outside of the NetBSD base system.

makefs enhancements

Project summary:

Recently, all ports but macppc and mac68k were switched from mkisofs to makefs for creation of bootable install CDs. The goal of this project is to add the missing features to makefs, so these two ports can be switched as well. If time allows, adding additional useful features would be a bonus.

Needed features:

  • Add Apple Type/Creator information to mtree spec file syntax.

  • Create Apple Extensions to ISO9660.

  • Merge two directory trees (mkisofs's graft points).

May be needed:

  • Create of hybrid HFS/ISO9660 image.

  • Install HFS boot file (possibly as separate post-processing step)

Additional features:

  • Create Joliet Extensions.

  • Print size of resulting image.

wcc(1)

Project summary:

Write a tool that combines wc(1) and cc(1). That is, a program that behaves like a compiler but instead of compiling generates accurate line counts. The idea is that you can do "env CC=wcc make" to get a line count out.

Note that this is not entirely trivial because each include file should be counted exactly once and you'll need machinery for combining counts (preserving this property) at "link" time.