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 are taking part in 2010 also.

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 Freenodes #netbsd-code or for pkgsrc-related discussions, #pkgsrc. If you want to just meet the community, visit #netbsd.

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 other package format(s) to pkgsrc Low
Authentication server meta-package Lowest
Binary compatibility for puffs backend Medium
Boot Images for NetBSD Appliances High
Convert eeprom drivers to proplib interface Low
Create a secure SASL (RFC2222) client implementation Low
Create an in-kernel API for "packet classes" High
Curses library automated testing Lowest
DTrace: fill in the gaps Medium
Enhance ptyfs to handle multiple instances Low
Evaluate, benchmark and optimize samba file server performance High
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
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
Improved Automounter Support High
In-kernel audio mixer High
JTAG Kit and Guide High
KGDB over Ethernet Medium
LED/LCD Generic API Medium
Light weight precision user level time reading Medium
NDMP Support Medium
NetBSD/aws -- Bringing NetBSD to Amazon's Web Services Lowest
New LPR/LPD for NetBSD Medium
OpenCrypto record-mode support for SSL and IPSEC Medium
OpenCrypto swcrypto(4) enhancements Medium
Optimize and speed-up ATF High
Port OpenAFS client support to NetBSD High
Reorganize ATF code to improve modularity High
Research converting system interfaces to XML High
Rewrite pkg_comp with portability as a major goal Medium
SMP support for prep High
Secure-PLT - supporting new PLT formats on alpha Medium
Socket option to timestamp UDP packets in the kernel Low
Sysinst alternative interface Medium
Sysinst enhancements Low
Unified isabeep driver Low
Userspace file system and device driver code sharing Lowest
libm improvements Medium
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 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.

Authentication server meta-package

Project summary:

pkgsrc is a very flexible package management system. It provides a comprehensible framework to build, test, deploy, and maintain software in its original form (with porter/packager modifications where applicable) as well as with site local modifications and customizations. All this makes pkgsrc suitable to use in diverse environments ranging from small companies up to large enterprises.

While pkgsrc already contains most elements needed to build an authentication server (or an authentication server failover pair), in order to install one, considerable knowledge about the neccessary elements is needed, plus the correct configuration, while in most cases pretty much identical, is tedious and not without pitfalls.

The goal of this project is to create a meta-package that will deploy and pre-configure an authentication server suitable for a single sign-on infrastructure.

Necessary tasks: provide missing packages, provide packages for initial configuration, package or create corresponding tools to manage user accounts, document.

The following topics should be covered:

  • PAM integration with OpenLDAP and DBMS;
  • Samba with PAM, DBMS and directory integration;
  • Kerberos setup;
  • OpenLDAP replication;
  • DBMS (PostgreSQL is a must, MySQL optional, if time permits), replication (master-master, if possible);
  • DNS server with a sane basic dynamic DNS update config using directory and database backend;
  • user account management tools (web interface, command line interface, see user(8) manual page, perhaps some scripting interface);
  • configuration examples for integration of services (web services, mail, instant messaging, PAM is a must, DBMS and directory optional).

All covered services should be documented, in particular documentation should include:

  • initial deployment instructions;
  • sample configuration for reasonably simple case;
  • instructions how to test if the software works;
  • references to full documentation and troubleshooting instructions (if any), both should be provided on-site (i.e. it should be possible to have everything available given pkgsrc snapshot and corresponding distfiles and/or packages on physical media).

In a nutshell, the goal of the project is to make it possible for a qualified system administrator to deploy basic service (without accounts) with a single pkg_add.

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:

Key parts of this project were completed in the 2009 Summer of Code project, “Miniaturize NetBSD”. The project this year is to improve the usability of the specification file format and to write a portable program that can parse a specification and direct the construction of a boot image.

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 secure SASL (RFC2222) client 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 users for mail delivery or forwarding with their outgoing mail server. The goal of this project is to provide a secure and flexible SASL client library.

The implementation should support at least plaintext password and hash-based challenge response authentication and should be extensible to other mechanisms like Kerberos. To demonstrate the use, either a simple SMTP/IMAP client or patches for Postfix should be provided.

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 is an automated test frame that is able to exercise the curses library functionality and compare the output with known good behaviour and is able to highlight any differences. There is a large body of work generating test cases and expected-output files to compare against that yet needs doing.

The successful student will end up knowing curses really well (if that wasn't a pre-existing condition).

This project runs under the existing NetBSD atf(7) framework.

DTrace: fill in the gaps

Project summary:

NetBSD recently added Sun's DTrace facility for kernel probing and debugging, as a set of kernel modules. Though the basic support for DTrace in the kernel are all in place, there is quite a bit of high-value work remaining to be done. In particular, it would be nice to have: Support for retrieving the DTrace buffers from kernel cores; machine-dependent code for any non-x86 processor; a version of the "profiling" provider Sun uses to collect performance data; a "syscall" provider that automatically generates static probes (trace points) for each system call entry and exit without requiring manual instrumentation of each system call; support for retrieving the DTrace buffers from kernel cores; support for tracing of userspace programs and across the user/kernel boundary (requires a version of Sun's "libproc").

DTrace is already very useful for debugging and measuring NetBSD but some or all of these enhancements would make it much more so.

Enhance ptyfs to handle multiple instances

Project summary:

Chrooted enviroments that need ptys cannot use ptyfs at this time because only one instance of ptyfs is supported. The task is to enhance ptyfs so that it can be mounted multiple times. The problems that need to be solved are:

  • The ptyfs code needs to be modified so that the correct path is returned depending on the mount point in the TIOCPTMGET ioctl. There was code there to do this, but it was removed because it was not working properly.
  • Since there can be only one instance of major/minor pty in the system, each mount point should only display the ptys that were created for that mountpoint and not others.
  • Since ptyfs replaces the handlers for the traditional BSD style ptys when it is mounted and puts them back once it is unmounted, this handler hijacking will not work with multiple mounts. Perhaps a solution is to do it only for the first mount?

This project is implemented all in the kernel and has no documentation requirements.

For extra credit you can investigate if providing continuous numbers (without gaps) is feasible without too much recoding, and implement it.

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.

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.

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.

Improved Automounter Support

Project summary:

NetBSD currently uses The Berkeley Automounter Suite of Utilities for automatically mounting (network) file systems. This software package implements an automounter file system as a userland NFS daemon. While this generally works it has major drawbacks:

  • File systems are not mounted directly on the desired mount point. As a result applications frequently use incorrect pathnames (e.g. /amd/server/home/user instead of /home/user) for automatically mounted directories or files beneath them. This is especially problematic in heterogeneous enviroments where not all machines use the same automounter.
  • The automounter daemon cannot handle high I/O load very well, file access occasionally fails with intermittent errors.

The goal of this project is to implement a new automounter solution which addresses the above issues. This could either be done via a Solaris/Linux compatible autofs(4) full in-kernel file system or via a userland daemon using puffs.

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:

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 already exists in other platforms, eg Linux and Mac OS X, using the normal remote GDB protocol, so it may be possible to reuse much of the existing KGDB stub.

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.

There is prior art in OpenBSD; it should be checked for suitability, and any resulting API should not differ from theirs without reason.

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(2) and gettimeofday(2). With the availability of user level readable high frequency counters it is possible to create fast implementations for precision time reading. Optimizing clock_gettime(2) 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.

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

This project is not intrinsically difficult, but will involve a rather large chunk of work to complete.

OpenCrypto record-mode support for SSL and IPSEC

Project summary:

The hardware supported by the nsp(4) driver, as well as much newer hardware (like Cavium Nitrox), can perform SSL/TLS and IPsec (ESP/ASH) record processing in single operations. It can also perform all processing for entire messages of each protocol (SSL/TLS/IKE)'s handshake in single operations. Extend OpenCrypto to efficiently support these record transforms and handshake operations and modify either netipsec or our in-tree openssl to use this support. SSL may be the easier target because NBMK generously open-sourced their complete package of detailed design and implementation documentation, along with (old) modified OpenSSL sources, along with the nsp(4) driver itself.

OpenCrypto swcrypto(4) enhancements

Project summary:

Use multiple cores efficiently (that already works reasonably well for multiple request streams); actually use faster versions of complex transforms (CBC, counter modes) from our in-tree OpenSSL or elsewhere (eg libtomcrypt); add support for asymmetric operations (public key). Tie public-key operations into veriexec somehow for extra credit (probably a very good start towards an undergrad thesis project).

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.

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 provide 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);.

Rewrite pkg_comp with portability as a major goal

Project summary:

pkg_comp is a shell script that allows building packages inside a sandbox in an automated manner. The goal is to allow the user to build packages in a controller manner and to provide a simple mechanism to build packages for a host running a specific NetBSD release (e.g building packages for NetBSD 5.x while running NetBSD-current).

The current version of pkg_comp is written as a pretty big shell script that has grown out of control. It is hard to maintain and hard to extend. And, more importantly, it is not portable at all.

The goal of this project is to rewrite pkg_comp from scratch with portability being the main goal: it has to be possible to use the script in different Unix variants (including Mac OS X).

The language of choice for the reimplementation will be Python. The code will be hosted outside of pkgsrc, in a Monotone repository, to be able to distribute it as a standalone tool.

The following items should be accomplished:

  • Implement a "sandbox" library with an interface to programmatically create and manage a sandboxed file system. The structure of the sandbox has to be configurable through a template, and templates have to be provided for a few systems. The sandbox itself will be constructed either by unpacking tarballs with the system contents (such as the NetBSD distfiles), by null-mounting directories of the host file system, or both.

  • Implement a command-line frontend utility for the "sandbox" library. This tool is completely unaware of pkgsrc but will be really nice to have (and trivial to write, as all the juicy bits are in the library). Will be useful as part of server administration, as it will allow isolating services in a fairly easy manner.

  • Implement the "pkg_comp" application, building it on top of the "sandbox" module. It has to provide most of the current functionality, if not all. More specifically, these are a must: unattended builds of a predefined set of packages and use of libkver to override the system version.

  • Implement detailed unit tests for the modules and integration tests for the front-end tools. At this point, the former will most likely be implemented using JUnit and the latter will be implemented using ATF.

As part of this project, the student will get familiar with pkgsrc, construction of sandboxes for different operating systems, unit testing, ATF, Python and the Monotone version control system.

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)

Secure-PLT - supporting new PLT formats on alpha

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.

This project (for alpha) is 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.

Socket option to timestamp UDP packets in the kernel

Project summary:

Many applications that use UDP unicast or multicast to receive data, need to store the data together with its reception time, or time the arrival time of packets as precisely as possible. This is required for example in order to be able to replay the data in simulated real-time to be able to do further performance analysis or quality control. Right now the only way to do this is to call recv(2)/recvmsg(2)/recvfrom(2) to grab the data, followed by gettimeofday(2)/clock_gettime(2). This is undesirable because:

  • It doubles the number of system calls limiting the effective maximum reception rate.
  • The timing of the packet is imprecise because there non-deterministic delay from the time that the packet hit the network adapter till the time userland received it.

Linux provides a socket control message to add timestamp ancillary data to the the socket, which can be controlled by 2 different socket options SO_TIMESTAMP and SO_TIMESTAMPNS, using setsockopt(2). This project is about implementing those options on NetBSD. Their implementation should be done as close to the code that does reception as possible to minimize timestamp delay. Perhaps even using the cards own clock if that's available.

This project is implemented all in the kernel, but you should provide some test programs as well as documentation.

For extra credit, design and implement an API that selects which clock is used, as well as providing information about available clocks, their precision and the position where the sampling is performed.

Sysinst alternative interface

Project summary:

The goal of this project is to provide an alternative version of the NetBSD system installer with a simple, X based graphical user interface.

The installer currently uses a "homegrown" (similar to CUA) text based interface, thus being easy to use over serial console as well as on a framebuffer console.

The current installer code is partly written in plain C, but in big parts uses C fragments embeded into its own definition language, preprocessed by the "menuc" tool into plain C code and linked against libterminfo.

During this project, the "menuc" tool is modified to optionally generate a different version of the C code, which then is linked against standard X libraries. The C stub fragments sprinkled throughout the menu definitions need to be modified to be reusable for both (text and X) versions. Where needed the fragments can just call C functions, which have different implementations (selected via a new ifdef).

Since the end result should be able to run off an enhanced install CD, the selection of widgets used for the GUI is limited. Only base X libraries are available. A look & feel similar to current xdm would be a good start.

Developement can be done on an existing system, testing does not require actuall installation on real hardware.

An optional extension of the project is to modify the creation of one or more port's install CD to make use of the new xsysinst.

The candidate must have:

  • familiarity with the system installer. You should have used sysinst to install the system.
  • familiarity with C and X programming.

The following would also be useful:

  • familiarity with NetBSD.
  • familiarity with user interface programming using in-tree X widgets.

References:

Sysinst enhancements

Project summary:

The goal of this project is to enhance the NetBSD system installer (sysinst) to provide additional support for (in order):

  • installation on multiple disks
  • installation on RAID
  • installation on cgd
  • installation on LVM
  • other enhancements

The installer currently suuports installing the system to any available single disk. It is possible to select which parts (distribution sets) of the system to install, and also to customise the disk partition layout. Sysinst can also use vnode psuedo disks, so can be tested without the need to re-install the host system.

The first goal is to add the support for multiple disks to sysinst. When this is finished, it will be possible to partition multiple disks, add filesystem mount points across the multiple disks, and to select the boot disk.

The second goal is to add support for creating and installing on to RAID (levels 0, 1 and 1+0) partitions. Note, that it is currently possible to install on to an existing RAID parition, but not to create one. When installing to RAID 1 or RAID 1+0, it should be possible to install the boot code to all of the mirror disks.

The third goal is to add support for creating and installing on to cgd (encrypted) partitions. The initial support will not be for the boot partition, but other partitions should be supported.

The fourth goal is to add support for creating and installing on to LVM Volume Groups and Logical Volumes. This should be similar to the RAID goal, above.

The other enhancements that might be possible are (not in priority order):

  • user interface
    • customise colours
    • add "back" and "forward" menu options
    • run parts of the installer independently (e.g. disk partitioning, set installation)
  • cgd enhancements
    • add the ability to encrypt the whole disk and to enter the decryption key at boot time
  • automated test setup
    • add the ability to install Anita for automated testing

The candidate must have:

  • familiarity with the system installer. You should have used sysinst to install the system.
  • familiarity with C programming. The system installer program consists of C code.
  • a test system, preferably with a 2nd bootable device.

The following would also be useful:

  • familiarity with NetBSD.
  • familiarity with user interface programming using curses.

References:

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.

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.

libm improvements

Project summary:

NetBSD math library (libm), which is a descendant of Sun's libm (just like other BSDs'), has quite a number of deficiencies:

  • It lacks an extensive unit test suite.
  • Some functions are not implemented, especially the long double versions.
  • There are problems with error handling, esp. floating point exceptions.
  • There's no proof of the implemented algorithms besides the comments and the bibliographic references in the code.
  • There's no documentation on average time, worst case time and memory consumption of the implemented algorithms.
  • There's no documentation on rounding modes and error bounds (for some functions the ULPs are mentioned in math(3) but the list isn't complete).

NetBSD is used for scientific computation, where some sort of quality assurance is non-negotiable. Moreover, a lot of modern dynamic languages rely on the operating system's libm implementation. Therefore, all errors in the library are propagated to upper layers, and sometime you observe unit tests failures (e.g. in Python and Ruby).

Goals of this project are:

  • create a certain number of unit tests for every math function, target correctness, precision, edge case stressing, error handling and other requirements of applicable standards (e.g. IEEE 754);
  • write code to generate series using available CAS or numeric software (optional);
  • improve error and exception handling;
  • implement missing functions;
  • provide missing documentation.

The candidate must know numeric analysis, understand numeric algorithms, understand floating point numbers implementation, know some general-purpose numeric software and/or computer algebra 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 a hybrid HFS/ISO9660 image.

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

Additional features:

  • Create Joliet Extensions.

  • Print size of resulting image.