NetBSD Projects

Project	Priority	Difficulty	Status
BSD licensed rsync replacement	Unspecified	Unspecified	Unassigned
BSD licensed troff/nroff replacement	Unspecified	Unspecified	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.

WiFi browser

Project summary:

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

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

Project	Priority	Difficulty	Status
Add DRM/DRI support (accelerated 3D graphics)	High	Medium	Unassigned
Add a kernel API for timed power-on	Low	Low	Unassigned
Compressed Cache System	Unspecified	Unspecified	Unassigned
Convert eeprom drivers to proplib interface	Low	Low	Unassigned
Convert kernel printf() to aprint_*() or log()	Lowest	Lowest	Unassigned
ENVSYS Version 2	Medium	Low	Assigned
Improve caching	Unspecified	Unspecified	Unassigned
Improve writing to the file system	Unspecified	Unspecified	Assigned
LED/LCD Generic API	Medium	Medium	Unassigned
More intelligent buffer queue management	Unspecified	Unspecified	Unassigned
NetBSD block device driver for NAND flash chips	Unspecified	Unspecified	Assigned
Real time support	Unspecified	Unspecified	Unassigned
Updated Atheros WiFi support	Unspecified	Unspecified	Unassigned

Add DRM/DRI support (accelerated 3D graphics)

Project summary:

• Priority: High
• Estimated difficulty: Medium
• Estimated length: 3-4 months
• Person/group of contact: tech-kern mailing list
• Person/group of contact: tech-x11 mailing list

Desktop environments are adding fancy graphical effects everywhere: translucid windows, real-time window resizing, shadows, etc. Strictly speaking, these effects do not provide any usability boost (some do), but the lack of them makes a desktop seem "underpowered" compared to friendlier systems (e.g. Mac OS X). All these effects use a 3D rendering library (OpenGL) and cannot be run if there is no hardware acceleration for them.

Similarly, most games from current days require 3D support. We can also add to the mix CAD and scientific applications such as those used in biology research.

Unfortunately, NetBSD does not have support for accelerated 3D graphics. This means that it will quickly fall behind in all the areas mentioned above as they advance. Specially in the desktop market, as these (GNOME and KDE) will soon start to incorporate more 3D effects.

The aim of this project is to implement 3D accelerated support in NetBSD. As this relies heavily on the drivers of specific cards, you should demonstrate that your implementation works by using any of the free 3D-aware drivers included in X.Org; the more, the better.

Adding 3D support is a matter of implementing DRM (Direct Rendering Module) and DRI (Direct Rendering Infrastructure). The former are a set of modules for the kernel that allow userland applications to communicate directly with the video card for optimal performance. The latter are the userland bits that provide 3D accelerated support: the video card drivers, the OpenGL libraries, etc. For more details check out the DRI site.

The biggest amount of work is to implement the DRM modules for all the supported video cards. Once this is done, the DRI bits from X.Org should be fairly easy to get to work as they communicate with DRM for the hardware-specific stuff.

Add a kernel API for timed power-on

Project summary:

• Priority: Low
• Estimated difficulty: Low
• Estimated length: 3-5 Weeks
• Person/group of contact: tech-kern mailing list

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 eeprom drivers to proplib interface

Project summary:

• Priority: Low
• Estimated difficulty: Low
• Estimated length: 4-6 Weeks
• Person/group of contact: tech-kern mailing list
• Person/group of contact: Tim Rightnour <garbled AT NetBSD.org>

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 openfirmware 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 dependant code.

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.

ENVSYS Version 2

Project summary:

• Priority: Medium
• Estimated difficulty: Low
• Estimated length: 1-2 months
• Person/group of contact: Tim Rightnour <garbled AT NetBSD.org>
• Person/group of contact: tech-kern mailing list
• Worked on by: Juan Romero Pardines <xtraeme AT NetBSD.org>

The envsys(4) system has a few shortcomings, which would be rather simple to address.

First, the envsys subsystem does not deal with detachable sensors well. This can be fixed by changing how we enumerate sensors, and how the kernel steps over the list of available sensors. See this post to tech-kern.

Additionally, some shortcomings were noted in this post to tech-kern, which should also be dealt with.

The whole system should be switched away from using the standard ioctl interface, to the new proplib interface between userland and the kernel.

Finally, the kevent mechanism should be utilized in the driver, to allow the user to set danger or warning threshold values on the environmental sensors, to alert them to overtemp conditions or the like.

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:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: 2 months
• Person/group of contact: tech-kern mailing list
• Worked on by: Sumantra R. Kundu <sumantra@gmail.com>, see the SoC 2006 "congest" project

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.

LED/LCD Generic API

Project summary:

• Priority: Medium
• Estimated difficulty: Medium
• Estimated length: 1-2 months
• Person/group of contact: Tim Rightnour <garbled AT NetBSD.org>
• Person/group of contact: tech-kern mailing list

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.

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:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: 2 months
• Person/group of contact: tech-embed mailing list
• Worked on by: Jared D. McNeill <jmcneill AT NetBSD.org>

Real time support

Project summary:

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

Support realtime signals and process scheduling according to POSIX standards.

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.

Project	Priority	Difficulty	Status
Add Subfiles to FFS	Unspecified	Unspecified	Unassigned
Add snapshots to tmpfs	Unspecified	Unspecified	Unassigned
BSD licensed JFS	Unspecified	Unspecified	Unassigned
BSD licensed XFS	Unspecified	Unspecified	Unassigned
Defragmentation for FFS	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
Port ZFS filesystem	Unspecified	Unspecified	Unassigned
Rewrite kernfs and procfs	Low	Medium	Unassigned
Simplify FFS	Unspecified	Unspecified	Unassigned

Add Subfiles to FFS

Project summary:

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

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

Defragmentation for FFS

Project summary:

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

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

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 <pooka@NetBSD.org> 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:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: Perry E. Metzger <perry AT NetBSD.org>
• Person/group of contact: tech-kern mailing list

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.

Port ZFS filesystem

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

Port Sun's ZFS filesystem to NetBSD. ZFS is currently licensed under Sun's CDDL, so a port (instead of a complete re-write) may therefore be prevented from inclusion in the source tree other than as a LKM. See also http://www.opensolaris.org/os/community/zfs/source/.

Porting the corresponding code from FreeBSD may offer a reasonable approach.

Rewrite kernfs and procfs

Project summary:

• Priority: Low
• Estimated difficulty: Medium
• Estimated length: 2-3 months
• Person/group of contact: Julio M. Merino Vidal <jmmv AT NetBSD.org>
• Person/group of contact: tech-kern mailing list

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.

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:

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

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:

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

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:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: tech-net mailing list
• Worked on by: Pavel Cahyna <pavel@NetBSD.org>, see the SoC 2006 "mbuf" project

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.

Project	Priority	Difficulty	Status
Cross-building support in pkgsrc	Medium	Medium	Unassigned
Parallel bulk builds	Unspecified	Unspecified	Assigned
Unprivileged pkgsrc builds	Unspecified	Unspecified	Assigned
pkg_install rewrite	Unspecified	Unspecified	Assigned

Cross-building support in pkgsrc

Project summary:

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

pkgsrc cannot currently cross-build any package: that is, build a package that can install and run on a system and/or architecture that is different to the one that built it. This feature could be very desirable to allow The NetBSD Project provide huge sets of binary packages for slow architectures, all of them built on super-fast i386 machines (as is currently done for the base system). At the moment, packages for foreign platforms need to be built natively, which can take from weeks to months to do a complete bulk-build. As expected, this is very inconvenient for end users, who don't have ready-to-use packages on machines where building software is painful, and also for developers, because they are unable to see whether their packages correctly build for those platforms they don't have.

The aim of this project is to add support for cross-building packages to pkgsrc. A lot of packages (those that use autoconf and automake properly) already have this functionality built in, so the changes to pkgsrc should be minimal. However, this has to be integrated properly into the pkgsrc build system, possibly also affecting the management tools.

In order to make things easier, the project can be simplified during the preliminary stages by only attempting to add support for NetBSD targets. This way, one can use the tools built by build.sh and a minimal system installed from NetBSD's sources as the minimum necessary environment to be able to cross-build the packages.

It's not a goal to port the packages themselves to be cross-buildable, as this is a huge task. However, those that support it "out of the box" should work. Of special interest is to get the X.Org packages to work, as this could allow the project to migrate from xsrc to a pkgsrc-based set of X.Org packages. Consider X.Org as a way to demonstrate that your cross-building support works and is really useful.

Parallel bulk builds

Project summary:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: tech-cluster mailing list
• Person/group of contact: tech-pkg mailing list
• Worked on by: Jörg Sonnenberger <joerg@NetBSD.org>

pkgsrc bulk builds — that is, building all available packages in sequence — are currently done without any parallelization. Changing the infrastructure to be aware of any clustered environments, delegating tasks to different nodes and building things in parallel whenever possible would greatly help us provide up-to-date packages much faster.

Some work as been done in this area (with a framework called “bobac”), but no fully functional solution is in place.

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 <joerg@NetBSD.org>

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:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: tech-pkg mailing list
• Worked on by: Jörg Sonnenberger <joerg@NetBSD.org>, see the SoC 2006 "pkg_install" project

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.

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, beeing 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!

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:

• Priority: High
• Estimated difficulty: Medium
• Estimated length: 1 week
• Person/group of contact: Julio M. Merino Vidal <jmmv AT NetBSD.org>
• Worked on by: Alan <jumpi AT netbsd.com.br>

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:

Clean up libgtop

Project summary:

• Priority: High
• Estimated difficulty: Medium
• Estimated length: 2 weeks
• Person/group of contact: Julio M. Merino Vidal <jmmv AT NetBSD.org>
• Worked on by: Igor Trindade Oliveira <vaxen AT gotfault.net>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>

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:

• Priority: Low
• Estimated difficulty: Lowest
• Estimated length: 2-3 days
• Person/group of contact: Julio M. Merino Vidal <jmmv AT NetBSD.org>
• Worked on by: James McHugh <james.mchugh AT nuigalway.ie>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>
• Worked on by: Magnus Henoch <mange AT freemail.hu>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>

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 <jmmv AT NetBSD.org>

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 shoudn't give too much trouble with HAL in place).

Project	Priority	Difficulty	Status
Add support for PowerPC 970 (Apple G5) CPU	Unspecified	Unspecified	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 MIPS64 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

Add support for PowerPC 970 (Apple G5) CPU

Project summary:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: port-macppc mailing list
• Person/group of contact: port-ofppc mailing list

NetBSD/macppc currently does not run on the Apple G5. Add support for the PowerPC 970 CPU. On a similar note, add support for the IBM POWER CPU (POWER III and up), which is important for NetBSD/ofppc.

Other Port suggestions

Project summary:

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

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

Port NetBSD to SGI Octane and Origin machines

Project summary:

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

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 <jschauma AT NetBSD.org>).

See also NetBSD/sgimips.

Support for MIPS16e ISA

Project summary:

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

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 MIPS64 ISA

Project summary:

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

NetBSD currently runs on 64-bit MIPS processors, but only in 32-bit mode. It would be nice to be able to run a true 64-bit OS on those processors.

Support for MMU-less systems

Project summary:

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

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:

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

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:

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

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.

Project	Priority	Difficulty	Status
Accelerated OpenGL	Unspecified	Unspecified	Unassigned
Cx	Unspecified	Unspecified	Unassigned
Flood-fill file distributor/syncer	Unspecified	Unspecified	Unassigned
Improve the SGI bootloader	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
NetBSD port of Qtopia Core Open Source Edition	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

Accelerated OpenGL

Project summary:

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

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.

Cx

Project summary:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: Perry E. Metzger <perry AT NetBSD.org>

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 <perry AT NetBSD.org>

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 the SGI bootloader

Project summary:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: 1-2 weeks
• Person/group of contact: port-sgimips mailing list

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

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

Improve 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:

• Priority: Unspecified
• Estimated difficulty: Unspecified
• Estimated length: Unspecified
• Person/group of contact: Perry E. Metzger <perry AT NetBSD.org>
• Person/group of contact: tech-install mailing list
• Person/group of contact: tech-userlevel mailing list

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:

NetBSD LiveCD with installer

Project summary:

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

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.

NetBSD port of Qtopia Core Open Source Edition

Project summary:

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

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

See also the Qtopia Core Open Source download.

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 dependend) 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:

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

syspkgs is the concept of using pkgsrc's pkg_* tools to maintain the base system. That is, allow users to register and delete/update/install 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.