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 August 04, 2008 at 05:36:32 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.

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
Compressed Cache System Unspecified Unspecified Unassigned
Convert kernel printf() to aprint_*() or log() Lowest Lowest Unassigned
Improve caching Unspecified Unspecified Unassigned
Improve writing to the file system Unspecified Unspecified Assigned
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

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.

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.

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

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
Policy routing Unspecified Unspecified Unassigned
Teredo: Tunneling IPv6 over UDP through NATs Unspecified Unspecified Unassigned
WLAN socket options 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.

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

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
Accelerated OpenGL Unspecified Unspecified Assigned
Unprivileged pkgsrc builds Unspecified Unspecified Assigned
pkg_install rewrite Unspecified Unspecified Assigned

Accelerated OpenGL

Project summary:

Make DRI and DRM work under NetBSD so that, at least, the free drivers included in a standard XFree86/X.Org distribution work in accelerated 2D and 3D modes.

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.

pkg_install rewrite

Project summary:

pkg_install, the set of binary utilities used to install, remove, create and (to some extent) update packages, has to be rewritten from scratch because the current code is very difficult to extend and modify. Aside from rewriting these tool set, it would be interesting to add new functionality (basically improve updates).

You can find more information about how the new tool would need to be in this tech-pkg@ thread.

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 support 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 GStreamer 0.8 Low Medium Unassigned
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 Mono High Highest 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 foldres 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 GStreamer 0.8

Project summary:

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

Drop gstreamer0.8 and gst-plugins0.8* after no other package uses them. You might attempt to port those applications that still use this old version to the newer 0.10 series.

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 Mono

Project summary:

  • Priority: High
  • Estimated difficulty: Highest
  • Estimated length: Unspecified
  • Person/group of contact: Julio M. Merino Vidal

GNOME 2.16 will include some applications in the core distribution that need the Mono runtime environment to work. There are also several very interesting applications out there that need Mono such as Beagle or F-Spot. Unfortunately, Mono does not work well under NetBSD yet.

It is expected that a lot of new software will be developed using Mono, so it is of high priority to get the runtime to work under NetBSD. Otherwise we will not be able to use Mono-based applications. Things can get a lot worse if one of these Mono-based programs ends up being a key component within the GNOME desktop.

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
Other Port suggestions 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

Other Port suggestions

Project summary:

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

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
Cx Unspecified Unspecified Unassigned
Flood-fill file distributor/syncer Unspecified Unspecified 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
Universal Interactive Wedge Editor Unspecified Unspecified Unassigned
Valgrind Unspecified Unspecified Unassigned
syspkgs Unspecified Unspecified Unassigned

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.

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.

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.