Skip to main content.

NetBSD Projects

BSD daemonThis page contains a non-exhaustive list of projects that either immediately benefit NetBSD or are of general interest to NetBSD and the Open Source Community. Most of the projects listed here have at least one NetBSD developer who has expressed interest and would be willing to assist/oversee the implementation to a certain degree.

A listing of possible NetBSD Summer-of-Code project suggestions can be found on the NetBSD Summer-of-Code page.

If you are interested in working on any of these projects, please contact the 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.

Some of the projects have timing estimates. Times are estimated conservatively, for a single person working full time on the project. An experienced developer, with knowledge of the changed subsystem/area of code, will probably be able to complete the project in half or less of the estimated time. As with all estimates, they might be wrong though — in both directions. Other projects include more research or have no hard target for other reasons. For these projects no estimate is given.

Available projects are grouped in the following areas and the lists were last updated on May 16, 2009 at 23:51:49 GMT:

You might find other ideas in src/doc/TODO and pkgsrc/doc/TODO. In addition, the NetBSD Port/Feature Cross Reference offers a large number of smaller projects: “just” implement all the missing (marked N) or partial features.

Generic userland work

Project Priority Difficulty Status
BSD licensed rsync replacement Unspecified Unspecified Unassigned
BSD licensed troff/nroff replacement Unspecified Unspecified Unassigned
Make enhancements Unspecified Lowest Unassigned
WiFi browser Unspecified Unspecified Unassigned

BSD licensed rsync replacement

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 2 months
  • Person/group of contact: tech-userlevel mailing list

Create a BSD licensed drop-in replacement for rsync that can handle large numbers of files/directories and large files efficiently. The idea would be to not scan the filesystem for every client to detect changes that need transfer, but rather maintain some database that can be queried (and that also needs updating when files are changed on the server). See supservers(8) for some ideas of how this could work. Compatibility with existing rsync clients should be retained.

BSD licensed troff/nroff replacement

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-userlevel mailing list

Write a replacement for groff that is BSD licensed. Earlier versions of BSD UNIX had one, so maybe it could be revived from an earlier version of BSD UNIX, and updated to support newer groff-like features, at least enough to support our current mandoc macros.

Note: In March, 2009, there was some discussion regarding a groff/-mandoc replacement on the tech-userlevel mailing list.

Make enhancements

Project summary:

BSD make (aka pmake) uses suffix rules (.c.o: ...) instead of pattern rules (%.c:%.o: ...) which are more general and flexible. The suffix module should be re-written so that is based on pattern rules, and pattern rules should be implemented. This will gain 90% compatibility with GNU make, and the rest (variable manipulations) can easily be added.

WiFi browser

Project summary:

Create an easy to use wifi setup widget for NetBSD: browse and select networks in the vicinity by SSID, BSSID, channel, etc.

Generic kernel work

Project Priority Difficulty Status
Add Subfiles to FFS Unspecified Unspecified Unassigned
Add a kernel API for timed power-on Unspecified Low Unassigned
Compressed Cache System Unspecified Unspecified Unassigned
Convert kernel printf() to aprint_*() or log() Lowest Lowest Unassigned
Defragmentation for FFS Unspecified Unspecified Unassigned
Flash translation layer Unspecified Medium Unassigned
Improve caching Unspecified Unspecified Unassigned
Improve writing to the file system Unspecified Unspecified Assigned
Installable cache control (or scheduling policies) Unspecified High Unassigned
More intelligent buffer queue management Unspecified Unspecified Unassigned
NetBSD block device driver for NAND flash chips Unspecified Unspecified Assigned
Updated Atheros WiFi support Unspecified Unspecified Unassigned

Add Subfiles to FFS

Project summary:

Subfiles are important for supporting the NT file model and will enhance Samba support. They are also important for NFSv4 (called Named Attributes) and are already supported by Sun Microsystems, Network Appliance, and EMC.

For a detailed project description see this post to tech-kern.

Add a kernel API for timed power-on

Project summary:

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

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

Compressed Cache System

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 2 months
  • Person/group of contact: tech-embed mailing list

NetBSD version of compressed cache system (for low-memory devices): http://linuxcompressed.sourceforge.net/.

Convert kernel printf() to aprint_*() or log()

Project summary:

  • Priority: Lowest
  • Estimated difficulty: Lowest
  • Estimated length: 2-4 Weeks
  • Person/group of contact: tech-kern mailing list

Most of the NetBSD kernel tree still uses printf(9) to send messages to the console, primarily during boot and autoconfiguration. Each printf during autoconfiguration should be audited, and replaced with the appropriate aprint_* function, to make the boot verbose option work properly.

Additionally, printfs in drivers that report status, or errors during normal kernel operation should be converted to use the log(9) function instead.

Defragmentation for FFS

Project summary:

Heavily used file systems tend to spread the blocks all over the disk, especially if free space is scarce. Traditionally dump/restore have been used to recreate the file system, but this is not acceptable for current disk sizes. Since resize_ffs has to relocate blocks during shrinking anyway, it should be possible to extend it to full reordering and defragmentation.

Flash translation layer

Project summary:

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

Improve caching

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 4 months
  • Person/group of contact: tech-kern mailing list

Replace all of the knobs and wacky algorithms for sizing the many separate LRU caches in our kernel (for pages and for various kinds of objects like metadata buffers, mbufs, etc.) with a generalized (N-way) algorithm like IBM's ARC ("Adaptive Replacement Cache") to size all the caches for optimal hit rate.

Improve writing to the file system

Project summary:

Apply TCP-like flow control to processes writing to the filesystem (put them to sleep when there is "congestion"), to avoid enormous backlogs and provide more fair allocation of disk bandwidth.

Installable cache control (or scheduling policies)

Project summary:

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

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

Caution: this is a research project.

More intelligent buffer queue management

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 2-3 months
  • Person/group of contact: tech-kern mailing list

NetBSD has a fixed, kernel-wide upper limit on transfer size, which is currently set to 64k on most port. This is too small to have good performances on modern IDE and SCSI hardware; on the other hand some devices can't do more than 64k, and in some case are even limited to less (the Xen virtual block device for example). Software RAID will also cause requests to be split in multiple smaller requests.

NetBSD would greatly benefit from a more intelligent buffer queue management between the block device drivers and the higher levels (the framework here currently only applies some selectable algorithm to sort the queue). This framework should be able to split buffers too large for a device into smaller ones, or aggregate multiple contiguous requests into a larger one. This will most probably require change to at last some block device drivers.

NetBSD block device driver for NAND flash chips

Project summary:

Updated Atheros WiFi support

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-kern mailing list

The latest Linux code in madwifi-ng includes a major code overhaul and support for advanced features (SuperAG @ 108Mbps, eXtended Range) available in these parts. It would be nice to have these features in NetBSD, under a BSD license.

Filesystems

Project Priority Difficulty Status
Add snapshots to tmpfs Unspecified Unspecified Unassigned
BSD licensed JFS Unspecified Unspecified Unassigned
BSD licensed XFS Unspecified Unspecified Unassigned
File system testing in usermode Unspecified Unspecified Assigned
Fix .. semantics, once and for all Unspecified Unspecified Unassigned
ISO9660 extensions Unspecified Unspecified Unassigned
Implement Ext3 file system support Low Medium Unassigned
Memory-usage policies for tmpfs Unspecified Unspecified Unassigned
Rewrite kernfs and procfs Low Medium Unassigned
Simplify FFS Unspecified Unspecified Unassigned

Add “snapshots” to tmpfs

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-kern mailing list

Add memory-efficient “snapshots” to tmpfs. A snapshot is a “view” of the filesystem, frozen at a particular point in time. The snapshotted filesystem is not frozen, only the view is. That is, you can continue to read/write/create/delete files in the snapshotted filesystem.

The interface to snapshots may resemble the interface to null mounts, e.g., 'mount -t snapshot /var/db /db-snapshot' makes a snapshot of /var/db/ at /db-snapshot/.

You should exploit features of the virtual memory system like “copy-on-write” memory pages to lazily make copies of files that appear both in a live tmpfs and a snapshot. This will help conserve memory.

BSD licensed JFS

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 1 year for port; 3 years for rewrite by one developer
  • Person/group of contact: tech-kern mailing list

Implement a BSD licensed JFS. A GPL licensed implementation of JFS is available at http://jfs.sourceforge.net/. It might be worthwhile to do a port of this filesystem and allow it to run as a LKM.

BSD licensed XFS

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 1 year for port; 3 years for rewrite by one developer
  • Person/group of contact: tech-kern mailing list

Implement a BSD licensed XFS. A GPL licensed implementation of XFS is available at http://oss.sgi.com/projects/xfs/. It might be worthwhile to do a port of this filesystem and allow it to run as a LKM. See also FreeBSD's port.

File system testing in usermode

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 2-3 months
  • Person/group of contact: tech-kern mailing list
  • Worked on by: Antti Kantee as part of the GSoC 2005 userfs project

Develop a set of libraries that permit compiling and running file system code in usermode. The primary purpose for these libraries is to permit running unit tests on the file system code.

Also develop a test interface and a number of test cases to use the libraries for testing file systems. The initial test cases should demonstrate the functionality of the test system.

Fix “..” semantics, once and for all

Project summary:

In a file system with symlinks, the file system becomes a graph rather than a tree. The meaning of “..” and the current working directory becomes somewhat ambiguous in such an environment.

Rob Pike implemented a neat way of fixing this for Plan 9. It is described in http://cm.bell-labs.com/sys/doc/lexnames.html. The project is simply to re-implement this for NetBSD.

ISO9660 extensions

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-kern mailing list

Add support for Apple's extensions to ISO9660 to makefs, especially the ability to label files with Type & Creator IDs. See http://developer.apple.com/technotes/fl/fl_36.html.

Implement Ext3 file system support

Project summary:

  • Priority: Low
  • Estimated difficulty: Medium
  • Estimated length: 1-2 months
  • Person/group of contact: tech-kern mailing list

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

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

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

Memory-usage policies for tmpfs

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-kern mailing list

Add configurable memory-usage policies to tmpfs, per discussions on NetBSD's tech-kern mailing list: % total memory, min/max kilobytes, etc.

Rewrite kernfs and procfs

Project summary:

kernfs is a virtual file system that provides the user several information about the current system and, in some cases, allows him to configure some aspects of the kernel through those virtual files. procfs is another virtual file system that provides information about the currently running processes.

These two file systems are written in a non-extensible way. For example, kernfs is built on a hardcoded table that always exposes the same set of files; there is no way for other system areas to add or remove entries from the kernfs contents. procfs has similar issues as someone might think of a subsystem that could benefit from attaching information of its own to each running process. The current code is not modular, not well-designed and, as time has shown, there probably remain serious security bugs in them.

Linux exposes some APIs that abstract procfs' contents and allow external code to manage its entries by adding or removing files and/ or directories. This is a very interesting feature when writing loadable kernel modules as they can use this virtual file system to provide a way of interaction with the end user.

NetBSD could benefit of similar APIs for both kernfs and procfs. This project would consist on adding these APIs, which most likely requires (or suggests) a full rewrite of these file systems. The developer should keep in mind the distinction between the two to avoid having a procfs similar to the one in Linux, which mixes system configuration and process management.

In order to keep the new implementations simple, the developer should investigate the possibility of using tmpfs as a backend for kernfs and procfs. With some changes, one could create a kernel "library" that allowed the creation of virtual file systems with few code. For example, it's unlikely that the directory management routines will change among the three file systems, so the code from tmpfs should be reused. Similarly other features should be reusable, making procfs's and kernfs's code a lot simpler than currently is.

Alternatively, investigate FreeBSD's pseudofs and see if this could be a useful for this project and base for all the file systems mentioned above.

When working in this project, it is very important to write a complete regression test suite for procfs and kernfs beforehand to ensure that the rewrites do not add incompatibilities.

Simplify FFS

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 8-12 months
  • Person/group of contact: tech-kern mailing list

Remove the residual geometry code and datastructures from FFS (keep some kind of “allocation groups” but without most of what cylinder groups now have) and replace blocks and fragments with extents, yielding a much simpler filesystem well suited for modern disks. The result would be useful to many operating systems beyond just NetBSD, since UFS/FFS is used in so many different kernels.

Networking

Project Priority Difficulty Status
802.11 operating scheme Unspecified Unspecified Unassigned
802.11 transmit queueing Unspecified Unspecified Unassigned
Ayame MPLS Unspecified Unspecified Unassigned
Cleanup routing code Unspecified Unspecified Unassigned
Generic SampleRate link-adaptation module Unspecified Unspecified Unassigned
Kismet Unspecified Unspecified Unassigned
Multicast DNS Unspecified Unspecified Unassigned
Policy routing Unspecified Unspecified Unassigned
Teredo: Tunneling IPv6 over UDP through NATs Unspecified Unspecified Unassigned
WLAN socket options Unspecified Unspecified Unassigned
Zeroconf Unspecified Unspecified Unassigned
mbuf audit Unspecified Unspecified Assigned

802.11 operating scheme

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

Design and program a scheme for extending the operating range of 802.11 networks by using techniques like “frame combining” and error-correcting codes to cope with low S/(N+I) ratio. Implement your scheme in one or two WLAN device drivers — Atheros & Realtek, say.

802.11 transmit queueing

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

Modern 802.11 NICs provide two or more transmit descriptor rings, one for each priority level or 802.11e access category. Add to NetBSD a generic facility for placing a packet onto a different hardware transmit queue according to its classification by pf or IP Filter. Demonstrate this facility on more than one 802.11 chipset.

Ayame MPLS

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

Integrate the Ayame MPLS stack into NetBSD-current.

Cleanup routing code

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 2 months
  • Person/group of contact: tech-net mailing list

Write tests for the routing code and re-factor. Use more and better-named variables.

PCBs and other structures are sprinkled with route caches (struct route). Sometimes they do not get updated when they should. It's necessary to modify rtalloc(), at least. Fix that. Note XXX in rtalloc(); this may mark a potential memory leak!

Generic SampleRate link-adaptation module

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

Create/modify a 802.11 link-adaptation module that works at least as well as SampleRate, but is generic enough to be re-used by device drivers for ADMtek, Atheros, Intel, Ralink, and Realtek 802.11 chips. Make the module export a link-quality metric (such as ETT) suitable for use in linkstate routing. The SampleRate module in the Atheros device driver sources may be a suitable starting point.

Kismet

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

Improve on the Kismet design and implementation in a Kismet replacement for BSD.

Multicast DNS

Project summary:

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

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

Policy routing

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 3 months
  • Person/group of contact: tech-net mailing list

Implement the ability to route based on properties like QoS label, source address, etc.

Teredo: Tunneling IPv6 over UDP through NATs

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

http://www.ietf.org/rfc/rfc4380.txt

WLAN socket options

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-net mailing list

Add socket options to NetBSD for controlling WLAN transmit parameters like transmit power, fragmentation threshold, RTS/CTS threshold, bitrate, 802.11e access category, on a per-socket and per-packet basis. To set transmit parameters, pass radiotap headers using sendmsg(2) and setsockopt(2).

Zeroconf

Project summary:

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

mbuf audit

Project summary:

Audit NetBSD for misuse of shared/read-only mbuf storage, and fix bugs as you find them. Improve the mbufs API to help developers protect against misuse in the future.

pkgsrc infrastructure

Project Priority Difficulty Status
Unprivileged pkgsrc builds Unspecified Unspecified Assigned

Unprivileged pkgsrc builds

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-pkg mailing list
  • Worked on by: Jörg Sonnenberger

To create packages that are usable by anyone, pkgsrc currently requires that packages be built with superuser privileges. It is already possible to use pkgsrc in great parts without such privileges, but there haven't been many thoughts about how the resulting binary packages should be specified. For example, many packages don't care at all about the owner/group of their files, as long as they are not publicly overwritable. In the end, the binary packages should be as independent from the build environment as possible.

For more information about the current state, see the “How to use pkgsrc as non-root” section in the pkgsrc guide, Jörg's mail on DESTDIR support as well as pkgsrc/mk/unprivileged.mk.

GNOME porting and packaging

Our goal is to make NetBSD a first-class supported platform under which the GNOME desktop can run to its full power. There is still a long way to achieve this and, truth to be told, it might be impossible to accomplish completely (on par to Linux) unless the GNOME developers are shown that they should care a bit more about portability and do part of the work themselves. At the moment only GNU/Linux can be considered a fully-supported platform, basically because almost all GNOME developers do their daily work under this operating system.

No matter what, we maintain that NetBSD is a very good and well designed free operating system, and we believe that it can also make a great desktop environment if it is able to support all the features included in GNOME. Furthermore, being good on the desktop will attract newer users, which in the long term means we will get new and fresh developers too!

This section contains a list of pending tasks that need to be resolved before the GNOME desktop can be considered fully-functional under a NetBSD system. Should you want to work on any of them, ask the contact person for further information. Many thanks in advance!

Important information

Before attacking any of the projects below, please take a look at the GNOME packaging and porting guide. It contains some important documentation about handling GNOME packages and patching their source code.

Now, the projects list:

Project Priority Difficulty Status
Add kqueue support to GNOME VFS High Medium Assigned
Clean up libgtop High Medium Assigned
Drop deprecated directories Lowest Lowest Unassigned
Feed back local patches High Medium Unassigned
Fix D-Bus regression tests High Medium Unassigned
Fix hardcoded paths in theme installer Low Lowest Assigned
Fix the Fast User Switch applet Low Unspecified Unassigned
Port Ekiga Low Low Assigned
Port GNOME Nettool Low Medium Unassigned
Port GNOME System Tools Lowest High Unassigned
Port Nautilus CD Burner Medium Low Unassigned

Add kqueue support to GNOME VFS

Project summary:

GNOME VFS provides an interface that allows monitoring external modifications to files and directories. The interface provides asynchronous notifications to the interested applications. For example, Nautilus uses them to update open folders in real time to reflect the real on-disk contents.

GNOME VFS uses the File Alteration Monitor (fam) to watch out for external file changes; this daemon made GNOME VFS completely unaware of the OS-specific mechanism used to receive asynchronous notifications. FAM was already ported to support NetBSD's kqueue framework, providing real time notifications of file changes.

However, starting from version 2.13.2, GNOME VFS implements support for inotify (a Linux-only interface) straight into its code. This means that FAM support will eventually disappear, most likely because this utility is unmaintained and because it needs to run with superuser privileges to monitor all files n the system. Therefore kqueue support needs to be integrated into GNOME VFS to ensure that it will continue to work when this happens. After that, we should be able to remove GNOME VFS' dependency on FAM, making GNOME installation much easier for the end user. See the instructions in pkgsrc/sysutils/fam/MESSAGE to understand this last point.

Assuming you are not familiar with kqueue, you might want to follow these steps to get started:

  1. Read the kqueue(2) manual page to get a general idea of the API and this example for starters.

  2. Analyze the kqueue support for FAM which is in pkgsrc/sysutils/fam/files/IMonKQueue.c++. This might be helpful to see how to apply kqueue to monitor for the events used by GNOME.

  3. Read the modules/inotify* files in gnome-vfs and inspect how they are used in the "file method". The modules/Makefile.am contains a list of related sources in the libfile_la_SOURCES variable.

  4. Possibly the hardest part: write the required stuff (modules/kqueue*) to add kqueue support.

Clean up libgtop

Project summary:

  • Priority: High
  • Estimated difficulty: Medium
  • Estimated length: 2 weeks
  • Person/group of contact: Julio M. Merino Vidal
  • Worked on by: Igor Trindade Oliveira

libgtop is a library that provides an abstract interface for querying system information such as the running process table, network status, etc. It is somewhat supported under NetBSD but there are still too many local patches in the pkgsrc packages (OK, some of them are specific to DragonFly BSD).

This is one of the hardest pieces to deal with when updating GNOME to a newer version. There are so many local changes and the code is so confusing that it is really complex to handle updates. Your task here is to clean up those local patches and feed them back to the mainstream authors.

A lot of extra bonus points if you redo the patches to avoid OS-specific precompiler macros completely and develop new configure tests instead. Really, there is no point in doing it differently.

For more details on how this should be done please see the patches and the bug reports filled back when we did previous cleanups:

Drop deprecated directories

Project summary:

  • Priority: Lowest
  • Estimated difficulty: Lowest
  • Estimated length: 1 week
  • Person/group of contact: Julio M. Merino Vidal

Drop the share/application-registry and share/mime-info directories from the xdg-dirs and xdg-x11-dirs packages when no package installs files in them. These two directories are not used and thus the files they hold can simply be removed. Your goal is to spot which packages still install files into those directories, create fixes for them, fill bug reports against the appropriate components to tell the authors about the issue (including the fixes you created) and, when accepted upstream, apply the patches to pkgsrc too.

This is not pkgsrc's task but we are in a great position to do this cleanup thanks to the PLISTs: it is really easy to spot packages that provide obsolete stuff in those directories.

Feed back local patches

Project summary:

  • Priority: High
  • Estimated difficulty: Medium
  • Estimated length: 1 month
  • Person/group of contact: Julio M. Merino Vidal

Feed back any portability patches in pkgsrc to the appropriate maintainers. There are many developers that add them but do not take the necessary steps to polish and submit them upstream. As a result, further updates become harder and harder due to the increasing number of local patches.

After submitting a patch, you might want to add a link to the upstream bug report in the patch's header to ease further tracking.

This task can be done by anybody, yet it is a very important one. You should note that it can also be very time consuming.

Fix D-Bus regression tests

Project summary:

  • Priority: High
  • Estimated difficulty: Medium
  • Estimated length: 1 week
  • Person/group of contact: Julio M. Merino Vidal

D-Bus is a new key component within the GNOME desktop. It is starting to be used by many different applications. Therefore, there should be high guarantees that it works as expected to avoid problems in unexpected places.

The easiest way to check this is by running D-Bus' regression tests and ensuring all tests pass. At the time of this writing, only two regression tests in dbus-0.92 failed under NetBSD 4.0_BETA. Diagnose and fix these.

To get started, enable the debug option in PKG_OPTIONS, rebuild sysutils/dbus from pkgsrc, enter the work directory and run gmake check manually to see the problems appear.

Fix hardcoded paths in theme installer

Project summary:

The theme installer included in GNOME's Control Center (capplets/theme-switcher/gnome-theme-installer.c) has several hardcoded paths to compression utilities such as tar, bzip2 or gzip. This is an obvious focus of portability problems and should be fixed by making the code dynamically locate the required tools in the path.

This problem does not expose under NetBSD itself because, by pure coincidence, the tools are located in the exact same pieces as in the developer's system. However, using pkgsrc under other platforms (e.g. a home-built Linux system) will certainly make it appear.

See GLib's g_find_program_in_path function to get started on the possible fix.

Fix the Fast User Switch applet

Project summary:

  • Priority: Low
  • Estimated difficulty: Unspecified
  • Estimated length: Unknown due to lack of details
  • Person/group of contact: Julio M. Merino Vidal

The Fast User Switch applet currently builds and installs fine under NetBSD as demonstrated by the x11/fast-user-switch-applet applet. Unfortunately it does not seem to work at all. Trying to switch to another user either does nothing or blocks the X server. Without having investigated the issue in depth, this is most likely a problem in GDM, not in the applet itself. Debug and fix this issue.

Port Ekiga

Project summary:

  • Priority: Low
  • Estimated difficulty: Low
  • Estimated length: Unknown due to lack of details
  • Person/group of contact: Julio M. Merino Vidal
  • Worked on by: Magnus Henoch

Ekiga, formerly known as GnomeMeeting, is a video conferencing application for the GNOME desktop. It is now part of GNOME's core desktop and therefore should be ported to NetBSD. A first step in porting and packaging this application is to get audio conferencing only to work, which should be quite easy.

Porting the video parts of Ekiga to NetBSD might be harder (if not impossible without Video4Linux) and therefore is not required for a preliminary working package.

Port GNOME Nettool

Project summary:

  • Priority: Low
  • Estimated difficulty: Medium
  • Estimated length: 1 week
  • Person/group of contact: Julio M. Merino Vidal

GNOME Nettool is a graphical frontend for several console-based networking applications such as netstat(1), ping(8) or route(8). GNOME Nettool currently builds and installs cleanly under NetBSD as demonstrated by the net/gnome-nettool package, but unfortunately it is completely useless.

Because this is just a frontend of console-based applications, GNOME Nettool needs to be taught about the NetBSD-specific input and output format of all the utilities it uses. It is interesting to note that GNOME Nettool currently includes support for the FreeBSD versions of all these tools so porting to NetBSD should be fairly straightforward. The applicant should have knowledge of these networking tools and has a FreeBSD system available to compare the existing calls in the code and their results with those needed in NetBSD.

Port GNOME System Tools

Project summary:

  • Priority: Lowest
  • Estimated difficulty: High
  • Estimated length: 1-2 months
  • Person/group of contact: Julio M. Merino Vidal

GNOME System Tools provides an abstraction layer to Unix-like system configuration. This tool is part of GNOME's core desktop, but is currently restricted to GNU/Linux operating systems. Your task is to port this utility to NetBSD, which is possibly a non-trivial task.

Port Nautilus CD Burner

Project summary:

  • Priority: Medium
  • Estimated difficulty: Low
  • Estimated length: Unknown due to lack of details
  • Person/group of contact: Julio M. Merino Vidal

Nautilus CD Burner is already in pkgsrc (sysutils/nautilus-cd-burner), and currently builds and installs successfully under NetBSD but it does not work at all. The most likely cause is the lack of HAL support, which forces the code to fall-back to non-existent OS-specific code for NetBSD.

Fixing this issue requires a working HAL port to avoid duplicating code in this utility. Then, try to see if it works (which shouldn't give too much trouble with HAL in place).

Missing ports and improvements

Project Priority Difficulty Status
Improve the SGI bootloader Unspecified Unspecified Unassigned
NetBSD port of Qtopia Core Open Source Edition Unspecified Unspecified Unassigned
Optimize for R10k CPUs in machines like the SGI O2 Unspecified High Unassigned
Other Port suggestions Unspecified Unspecified Unassigned
Port NetBSD to SGI Octane and Origin machines Unspecified Unspecified Unassigned
Support for MIPS16e ISA Unspecified Unspecified Unassigned
Support for MMU-less systems Unspecified Unspecified Unassigned
Support for sun4v (UltraSPARC T1) Unspecified Unspecified Unassigned
Xen: implement save/restore feature Unspecified Unspecified Unassigned

Improve the SGI bootloader

Project summary:

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

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

A secondary objective of this project would be to rearrange the generation of a bootably CD image so that it could just be loaded from the firmware menu without going through the command monitor.

NetBSD port of Qtopia Core Open Source Edition

Project summary:

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

See also the Qtopia Core documentation and this mail.

Optimize for R10k CPUs in machines like the SGI O2

Project summary:

NetBSD/sgimips currently runs on O2s with R10k (or similar) CPUs, but for example speculative loads are not handled correctly. It is unclear if this is pure kernel work or the toolchain needs to be changed too.

See also NetBSD/sgimips.

Other Port suggestions

Project summary:

See this page for ideas about suggested ports or not yet integrated ports.

Port NetBSD to SGI Octane and Origin machines

Project summary:

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

See also NetBSD/sgimips.

Support for MIPS16e ISA

Project summary:

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

Support for MMU-less systems

Project summary:

NetBSD currently requires a system with an MMU. This obviously limits the portability. We'd be interested in an implementation/port of NetBSD on/to an MMU-less system.

Support for sun4v (UltraSPARC T1)

Project summary:

It would be nice to support these newer highly SMP processors from Sun. A Linux port already exists, and Sun has contributed code to the FOSS community.

Xen: implement save/restore feature

Project summary:

Xen (2 and 3) can save/restore (and migrate, but from the guest POW it's the same thing) a domain. Some support is needed in guest operating system, and right now NetBSD lacks this support. This is mostly suspend/resume in virtual device drivers, and in the pmap.

Miscellaneous work

Project Priority Difficulty Status
Create a secure SASL (RFC2222) implementation Unspecified Low Unassigned
Cx Unspecified Unspecified Unassigned
Flood-fill file distributor/syncer Unspecified Unspecified Unassigned
IMAPfs for mail Unspecified Highest Unassigned
Improve website infrastructure Unspecified Unspecified Unassigned
Modern CD/Disk-on-key installer Unspecified Unspecified Unassigned
NetBSD LiveCD with installer Unspecified Unspecified Unassigned
Port of the NVIDIA graphics driver Unspecified Unspecified Unassigned
System log monitoring Unspecified Lowest Unassigned
Universal Interactive Wedge Editor Unspecified Unspecified Unassigned
Valgrind Unspecified Unspecified Unassigned
syspkgs Unspecified Unspecified Unassigned

Create a secure SASL (RFC2222) implementation

Project summary:

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

Additional integration with pkgsrc would be a bonus.

Note: check dovecot and evaluate it.

Cx

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: Perry E. Metzger

Perry E. Metzger has come up with an experimental idea on how to improve NetBSD code quality and security on an ongoing basis. To test the idea out, we will need a translator between a new, experimental language (called Cx) and C. The student should feel comfortable with using lex and yacc, and should understand the principles of compiler technology, particularly the contents of a book like the Dragon book.

Flood-fill file distributor/syncer

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: Perry E. Metzger

Maintaining multiple anonymous cvs/svn/ftp/etc. repositories on a global basis can be a challenge. Implement a novel method of maintaining large numbers of replicas of a master repository, based on a secure "flood fill" protocol. If time is available, also implement kernel hooks to make the change-set generation system substantially more efficient.

IMAPfs for mail

Project summary:

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

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

Improve website infrastructure

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: netbsd-docs mailing list

The NetBSD website building infrastructure is rather complex and requires significant resources. We need to make it easier for anybody to contribute without having to install a large number of complex applications from pkgsrc or without having to learn the intricacies of the build process.

A more detailed description of the problem is described in this and this email and the following discussion on the netbsd-docs mailing list.

This work requires knowledge of XML, XSLT and make. This is not a request for visual redesign of the website.

Modern CD/Disk-on-key installer

Project summary:

The NetBSD install system currently assumes that it needs to live in a memory and disk constrained environment. This is no longer the case. For this project:

  1. Redo the current SSTO based installer to boot directly from an ISOFS or ffs-on-disk-on-key environment.

  2. Clean up the install system to take advantage of the newer, better install environment.

NetBSD LiveCD with installer

Project summary:

While NetBSD has had LiveCDs for a while, there has not yet been a LiveCD that allows users to install NetBSD after test-driving it. A LiveCD that contains a GUI based installer and reliably detects the platforms features would be very useful.

Port of the NVIDIA graphics driver

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-kern mailing list

Port the FreeBSD driver for NVIDIA graphic adapter distributed by NVIDIA. Most of the work happens in the kernel, but making the userland part work with XFree86/X.Org and Linux binary emulation is needed too.

System log monitoring

Project summary:

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

Universal Interactive Wedge Editor

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: 1-2 months
  • Person/group of contact: tech-userlevel mailing list

Due to the multitude of supported machine architectures NetBSD has to deal with many different partitioning schemes. To deal with them in a uniform way (without imposing artificial restrictions that are not enforced by the underlying firmware or bootloader partitioning scheme) wedges have been designed.

While the kernel part of wedges is mostly done (and missing parts are easy to add), a userland tool to edit wedges and to synthesize defaults from (machine/arch dependent) on-disk content is needed.

Valgrind

Project summary:

  • Priority: Unspecified
  • Estimated difficulty: Unspecified
  • Estimated length: Unspecified
  • Person/group of contact: tech-kern mailing list

Port valgrind to NetBSD for pkgsrc, then use it to do an audit of any memory leakage.

See also http://valgrind.org and http://vg4nbsd.berlios.de for work in progress.

syspkgs

Project summary:

syspkgs is the concept of using pkgsrc's pkg_* tools to maintain the base system. That is, allow users to register and components of the base system with more ease. There has been a lot of work in this area already, but it has not yet been finalized.