This 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 $Date: 2008/08/04 05:36:32 $: 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. 0 0 1 month tech-net tech-userlevel Create an easy to use wifi setup widget for NetBSD: browse and select networks in the vicinity by SSID, BSSID, channel, etc. 0 1 1 month tech-toolchain 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. 0 0 2 months tech-userlevel 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 &man.supservers.8; for some ideas of how this could work. Compatibility with existing rsync clients should be retained. 0 0 Unspecified tech-userlevel 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. 0 0 4 months tech-kern 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. 0 0 2 months tech-kern 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. 0 0 2 months tech-embed &a.jmcneill; jmcneill AT NetBSD.org 0 0 2 months tech-embed NetBSD version of compressed cache system (for low-memory devices): . 0 0 Unspecified tech-kern 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. 0 0 2-3 months tech-kern 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. 1 1 2-4 Weeks tech-kern Most of the NetBSD kernel tree still uses &man.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 &man.log.9; function instead. 0 0 8-12 months tech-kern 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. 0 0 1 year for port; 3 years for rewrite by one developer tech-kern Implement a BSD licensed XFS. A GPL licensed implementation of XFS is available at . It might be worthwhile to do a port of this filesystem and allow it to run as a LKM. See also FreeBSD's port. 0 0 1 year for port; 3 years for rewrite by one developer tech-kern Implement a BSD licensed JFS. A GPL licensed implementation of JFS is available at . It might be worthwhile to do a port of this filesystem and allow it to run as a LKM. 0 0 2-3 months tech-kern &a.pooka; 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. 3 5 2-3 months &a.jmmv; jmmv AT NetBSD.org tech-kern 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. 0 0 Unspecified &a.perry; perry AT NetBSD.org tech-kern 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 . The project is simply to re-implement this for NetBSD. 0 0 Unspecified tech-kern 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. 0 0 Unspecified tech-kern Add configurable memory-usage policies to tmpfs, per discussions on NetBSD's tech-kern mailing list: % total memory, min/max kilobytes, etc. 0 0 Unspecified tech-kern Add support for Apple's extensions to ISO9660 to makefs, especially the ability to label files with Type & Creator IDs. See . 0 0 Unspecified tech-net 0 0 Unspecified tech-net Improve on the Kismet design and implementation in a Kismet replacement for BSD. 0 0 3 months tech-net Implement the ability to route based on properties like QoS label, source address, etc. 0 0 2 months tech-net 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! 0 0 Unspecified tech-net 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 &man.sendmsg.2; and &man.setsockopt.2;. 0 0 Unspecified tech-net 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. 0 0 Unspecified tech-net 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. 0 0 Unspecified tech-net Integrate the Ayame MPLS stack into NetBSD-current. 0 0 Unspecified tech-net 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. 0 0 Unspecified tech-net 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. 0 0 Unspecified tech-pkg 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. 0 0 Unspecified tech-pkg 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. 0 0 Unspecified tech-kern tech-x11 &a.bjs; bjs@NetBSD.org 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. 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! 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: 8 6 1 week &a.jmmv; 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. 8 6 2 weeks &a.jmmv; jmmv AT NetBSD.org 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: 103086: Extra libraries required in pkgconfig file 135674: Add NetBSD support and fix some problems in *BSD 139809: Argument passing between library and server broken 337207: msg_limits.c build broken in NetBSD 337234: Obsolete code in proctime.c breaks the build under NetBSD 337235: fsusage.c broken in NetBSD (no statfs) 337246: Missing GLIBTOP_SUID_* declarations in sysdeps 337247: freebsd sysdeps need to link against libkvm 337251: freebsd sysdeps miss glibtop_get_sysinfo_s 7 9 Unspecified &a.jmmv; 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. 7 5 1 week &a.jmmv; jmmv AT NetBSD.org 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: Read the kqueue(2) manual page to get a general idea of the API and this example for starters. 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. 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. Possibly the hardest part: write the required stuff (modules/kqueue*) to add kqueue support. 5 4 Unknown due to lack of details &a.jmmv; 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 shouldn't give too much trouble with HAL in place). 4 0 Unknown due to lack of details &a.jmmv; 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. 2 8 1-2 months &a.jmmv; 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. 3 6 1 week &a.jmmv; 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. 3 2 2-3 days &a.jmmv; jmmv AT NetBSD.org 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. 3 3 Unknown due to lack of details &a.jmmv; jmmv AT NetBSD.org 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. 8 5 1 month &a.jmmv; 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. 2 1 1 week &a.jmmv; 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. 3 5 Unknown due to lack of details &a.jmmv; 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. 0 0 4 months tech-misc tech-ports 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. 0 0 Unspecified port-sparc tech-ports 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. 0 0 Unspecified port-xen tech-kern 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. 0 0 Unspecified tech-embed tech-ports See this page for ideas about suggested ports or not yet integrated ports. 0 0 1-2 months tech-userlevel 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. 0 0 Unspecified tech-kern 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. 0 0 Unspecified tech-install tech-misc 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. 0 0 Unspecified tech-kern Port valgrind to NetBSD for pkgsrc, then use it to do an audit of any memory leakage. See also and for work in progress. 0 0 Unspecified netbsd-users tech-install 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. 0 0 Unspecified &a.perry; perry AT NetBSD.org tech-install tech-userlevel 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: Redo the current SSTO based installer to boot directly from an ISOFS or ffs-on-disk-on-key environment. Clean up the install system to take advantage of the newer, better install environment. 0 0 Unspecified netbsd-docs 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. This work requires knowledge of XML, XSLT and make. This is not a request for visual redesign of the website. 0 0 Unspecified &a.perry; perry AT NetBSD.org &a.perry; 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. 0 0 Unspecified &a.perry; 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.