Skip to main content.

NetBSD Summer-of-Code Projects

BSD daemonNetBSD participated successfully in Google's Summer of Code 2005, 2006, 2007, 2008 and 2009. We will proud to apply again as a mentoring organization in this year's Summer of Code program.

This page contains a list of concrete suggestions for projects we would like to see applications for in the next Summer of Code. 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, #netbsd-code or, for pkgsrc-related discussions, #pkgsrc.

We encourage you to come up with your own suggestions, if you cannot 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 hardware bridge support to bridge(4) High
Add other package format(s) to pkgsrc Low
Binary compatibility for puffs backend Medium
Boot Images for NetBSD Appliances High
Convert eeprom drivers to proplib interface Low
Create a L2TP (RFC 2661) pseudo device Medium
Create an in-kernel API for "packet classes" High
Curses library automated testing Lowest
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
Framebuffer driver for S3 Virge and/or S3/Trio 64 Low
Framebuffer driver for old Matrox cards Low
Framebuffer support for libsa Medium
GPT aware boot loader support Medium
Graceful USB disk detach/reattach High
ISDN NT support and Asterisk integration Medium
Implement file system flags to scrub data blocks before deletion Low
Improve and extend libintl Low
Improve support for Ext2 root file system Low
Improve/Extend file system resizer Medium
Improving RAIDframe parity check after unclean shutdown Medium
In-kernel audio mixer High
JTAG Kit and Guide Medium
KGDB over Ethernet Medium
LED/LCD Generic API Medium
Light weight precision user level time reading Low
Miniaturize NetBSD Medium
NAND Flash device driver High
NDMP Support Medium
NetBSD/aws -- Bringing NetBSD to Amazon's Web Services Low
New LPR/LPD for NetBSD Lowest
Optimize and speed-up ATF High
Package update tool similar to apt-get/yum Medium
Physical address-space manager Highest
Port OpenAFS client support to NetBSD High
Reorganize ATF code to improve modularity High
Research converting system interfaces to XML High
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
Unified isabeep driver Low
Userland daemon for the in-kernel PPPoE server Low
Userspace file system and device driver code sharing Lowest
WiFi Packet Visualizer Medium
XML utilities High
makefs enhancements 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 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.

Binary compatibility for puffs backend

Project summary:

Currently, the puffs(3) interface between the kernel and userspace uses various system structures for passing information. Examples are struct stat and struct uucred. If these change in layout (such as with the recent time_t size change), old puffs servers must be recompiled.

The purpose of the project is to:

  • define a binary-independent protocol
  • implement support
  • measure the performance difference with direct kernel struct passing
  • if there is a huge difference, investigate the possibility for having both an internal and external protocol. The actual decision to include support will be made on the relative complexity of the code for dual support.

While this project will be partially implemented in the kernel, it is fairly well-contained and prior kernel experience is not necessary.

If there is time and interest, a suggested subproject is making sure that p2k(3) does not suffer from similar issues. This is a required subproject if dual support as mentioned above is not necessary.

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.

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.

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

Curses library automated testing

Project summary:

The curses library is an important part of the NetBSD operating system, many applications rely on the correct functioning of the library. Performing modifications on the curses library can be difficult because the effects of the change may be subtle and can introduce bugs that are not detected for a long time. To detect undesired effects of changes there needs to be an automated test frame that is able to exercise the curses library functionality and compare the output with known good behaviour and be able to highlight any differences.

This project must be designed to run under the existing NetBSD atf(7) framework.

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?"

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

GPT aware boot loader support

Project summary:

The Master Boot Record (MBR) layout widely used on i386 and amd64 machines can address no more that 232 blocks, 512 bytes size each. This implies that neither the maximum size of a partition nor the maximum start address (both in bytes) can exceed 512×232 bytes, or 2 TiB. Capacity of modern disk subsystems can easily extent over 2 TiB in size thus requiring new disk partitioning scheme. As de-facto standard the GUID Partition Table (GPT) is used. NetBSD have GPT support via disk wedges (dk(4)) and gpt(8) utility, but can't be natively boot off a GUID partition.

There are two standard ways to load kernel off the GPT: use EFI, or add GPT support to mbr(8), bootxx (first stage bootloader), and boot(8) (second stage kernel loader). This project is about implementing the second approach.

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?

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 file system flags to scrub data blocks before deletion

Project summary:

This project requires the implementation of a new mount option, and a new system and user file system flag, which, when set, will write random data over file system blocks before they are to be deleted. In the NetBSD kernel, this will take place at the time of the last unlink of a file, and when ftruncate is called.

The project will involve the investigation of retrieving or generating random data within the kernel, along with research into ways of retrieving large amounts of low-quality random data, such as LSFR, Mersenne twisters, and PRNGs. As well as implementing the file system flags within the kernel, user-level programs and library functions which manipulate the flags will need to be modified. Documentation detailing the new functionality must also be provided.

Improve and extend libintl

Project summary:

NetBSD provides a BSD licensed implementation of libintl. This implementation is based on the specifications from GNU gettext. It has not kept up with the development of gettext in the last few years though, lacking e.g. support for context specific translations. NetBSD currently also has to depend on GNU gettext to recreate the message catalogs.

Goals for this projects include:

  • Restore full API compatibility with current gettext. At the time of writing, this is gettext 0.17.
  • Implement support for the extensions in the message catalog format. libintl should be able to process all .mo files from current gettext and return the same results via the API.
  • Provide a clean implementation of msgfmt.
  • Other components of gettext like msgmerge and the gettext frontend should be evaluated case-by-case if they are useful for the base system and whether third party software in pkgsrc depends on them.

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

In-kernel audio mixer

Project summary:

NetBSD's audio subsystem does not support playing back multiple streams concurrently. This can be achieved in userland, but this introduces latency and requires applications to be written against the sound server's specific API.

This project should add support to the native NetBSD audio APIs for low-latency mixing of channels that is completely transparent to existing applications, and extend the audio subsystem's userland interface to allow per-stream volume controls for new applications.

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.

KGDB over Ethernet

Project summary:

  • Estimated difficulty: Medium
  • Person/group of contact: Andreas Gustafsson

NetBSD currently supports remote kernel debugging using gdb over a serial connection. In new hardware, serial ports are becoming increasingly rare, but Ethernet interfaces are now ubiquitous. To ensure the continued ability to debug kernels on new hardware, it would be useful for NetBSD to support Ethernet as a KDGB transport.

Similar functionality is reported to already exist for Linux and Mac OS X, so it may be possible to reuse existing network protocols and/or GDB-side code.

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.

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.

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.

NetBSD/aws -- Bringing NetBSD to Amazon's Web Services

Project summary:

Amazon Web Services offers virtual hosts on demand via its Amazon Elastic Comput Cloud (or EC2). Users can run a number of operating systems via so-called "Amazon Machine Images" (AMIs), currently including various Linux flavors and OpenSolaris, but not NetBSD.

This project would entail developing a NetBSD "AMI". At this point, the level of effort required has not yet been determined, but it will include creating a NetBSD/xen image that includes the required Amazon-specific tools (which may need to be packaged first). It is unclear whether or not EC2 can boot a NetBSD kernel, and if not, what kind of effort is required to make this happen.

Based on the above uncertainties, this project may vary in complexity. The student would be required to do a lot of independent research (and/or have experience with AWS/EC2) and the final project goals may be adjusted based on what is discovered in the process.

An ideal project outcome would be a tool/mechanism to generate NetBSD AMIs as part of our regular release process and make them available to our users for their use within the Amazon Cloud.

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.

Optimize and speed-up ATF

Project summary:

atf(7) (Automated Testing Framework) is the testing framework used to write tests for the NetBSD system and run them in an unattended manner. At the moment, the execution of the tests is very slow because most of the test programs are written using sh(1) and all the backing framework for this language binding is slow. The goal of this project is to optimize and/or speed-up ATF to reduce the overall time required to execute the full NetBSD test suite.

There are several ideas that can be worked on as part of this project:

  • Speed up the atf-sh binding. It is yet unclear how to do this. The student should profile the current sh(1) code and see what parts of it can be optimized and/or migrated to native code. We suspect that the biggest culprit here (at least when running ATF in OS X) is the continuous spawning of subprocesses to perform helper tasks; this has yet to be demonstrated, though.
  • Add more features to the C/C++ interface so that most test programs written using the atf-sh binding can be rewritten in either atf-c or atf-c++. Just notice how much faster the execution of the atf-c and atf-c++ tests compared to all others.
  • Parallelize atf-run so that different test programs can be run in parallel. This will require changes to the Atffiles so that the programmer can group test programs to specify whether they can be run in parallel or not. Part of your job will be adding support for specifying that some tests depend on others.

As part of this project, the student will get familiar with ATF internals, unit testing, the Monotone version control system, the GNU build system and the internals of the NetBSD test suite.

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

Reorganize ATF code to improve modularity

Project summary:

The current C/C++ bindings in atf(7) expose way too much internal details to the programmer. This is bad because the test program writter can easily end up using internal APIs, increasing the maintenance burden every time a new version of ATF is released. The goal of this project is to reorganize the ATF code in a way that internal details (such as auxiliary data types and the implementation of public types) are hidden.

The following items should be accomplished:

  • Implement the pimpl idiom in all C and C++ public structures/classes to decrease coupling among modules. Trivial to do in C++ but will require some more work in C to provide a generic interface to do this per module.
  • Add "forward declaration" headers for all modules, similar to the split of error.h and error_fwd.h.
  • Split the ATF libraries into a generic library and an ATF-specific library, both for the C and C++ bindings. The current libraries provides lots of helper modules to manage, for example, paths, files, linked lists, etc. that shouldn't be exported to users. If kept internal/unstable, there is less maintenance overhead because refactoring of these modules could be performed without considering API/ABI compatibility issues.
  • Split the distfile into multiple ones. The idea is to have the following distfiles: libaux-c, libaux-c++, libatf-c, libatf-c++, libaux-c-tests, libaux-c++-tests and atf-tools at least. (libaux is just a representative name for the new module added in the previous item. It is by no means the name the library should have.) The reason behind this change is to remove the C++ dependency from packages that do not require C++ at all yet they want to provide their own test programs in C.

As part of this project, the student will get familiar with ATF internals, unit testing, the Monotone version control system and the GNU build system.

Research converting system interfaces to XML

Project summary:

System interfaces are currently specified as C prototypes, C preprocessor macros and C structures. This limits the ability to do automatic processing with them. There are some cases in the tree which implement an ad-hoc domain specific language and a script producing a C representation of the data, for example vnode_if.src and namei.src.

The goal of the project is to come up with a specification language and test it by rewriting a considerable subset of the current C headers in it. A translator for generating the C representations and documentation should also be implemented. Finally, the student should suggest and implement any other use for the translator. An example is autogenerating code to print structures in a human-readable form from the ddb kernel debugger.

This is more of a research project than a simple implementation. The goals are very loosely set now, but should be exactly specified by the student in the application.

For honors, a static analyzer examining if calls are made with the correct type of flag arguments can be written as the third requirement. It would warn about for example malloc(s, M_TEMP, PR_WAITOK);.

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.

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.

Userspace file system and device driver code sharing

Project summary:

As is well-known, puffs(3) is the NetBSD userspace file system framework. It provides support for implementing file servers in userspace. A lesser known "cousin" of puffs is the Pass-to-Userspace Device, or pud(4) framework, which provides support for implementing character and block device servers in userspace. Both use putter(9) for transmitting requests to and from the kernel.

Currently, puffs includes a userspace support library: libpuffs. It provides two facets:

  • file system routines and callback interface
  • generic parts, including kernel request handling

On the other hand, pud is without a userspace support library and servers talk with kernel directly with read() and write().

The goal of the project is to modify libpuffs into a generic library which pud and puffs can share, and provide libpuffs and libpud built on this base. The submission should include a rough analysis of the source modules of libpuffs and what is going to happen to them during the project.

This project is fairly straightforward, but involves a reasonable amount of work. Plenty of documentation exists to make the learning curve manageable. This project is an excellent opportunity to practise getting your hands dirty with real world systems.

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:

WiFi Visualizer Diagram

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.

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.