NetBSD participated successfully in Google's summer of code 2005, 2006 and 2007. We are proud to have been selected as a mentoring organization again in 2008! This page contains a list of concrete suggestions for projects we would like to see applications for. Note that they vary a lot in required skills and difficulty. We hope to get applications with a broad spectrum. If you are interested in working on any of these projects, please contact the developer and/or mailing list referenced next to each item, and possibly answer as many questions from our Project Application HowTo as possible. The interested developers will be glad to respond to you there. In addition, you may wish to discuss your proposal on IRC -- look for us on #netbsd-code. We encourage you to come up with your own suggestions, if you can not find a suitable project here. You can find more project ideas on the NetBSD project ideas page. These are not directly applicable to Summer-of-Code, but may serve as ideas for your own suggestions. You might find other ideas in src/doc/TODO and pkgsrc/doc/TODO. Deadlines and directions for students' applications to the Google Summer-of-Code can be found on the Google pages. 5 &a.martin; martin AT NetBSD.org tech-kern This projects has two subprojects: add support for the NT (network) side of ISDN to the NetBSD ISDN stack and interface ISDN (in NT mode) to the Asterisk PBX, which would allow using existing ISDN PBXes as SIP/VoIP phones, as well as easier testing of new ISDN card drivers. Previous work in this area can be found at the alternative ISDN driver site. 9 &a.martin; martin AT NetBSD.org &a.jmcneill; jmcneill AT NetBSD.org tech-kern NetBSD is lacking a framework for DVB (digital video broadcast) receivers. This project should create such a framework and deliver at least one driver for a DVB card making use of the framework. Further userland work will be needed, for example adapting mythTV to this new kernel API, but this is not part of the project. A major part of this project is designing the kernel subsystem. There are several alternative approaches: follow the LinuxTV model, which is now used by OpenSolaris too, or go for a solution similar to DirectShow. There also is ongoing work in FreeBSD, and of course it would be possible to develop a simple NetBSD specific API (creating slightly more work for porting existing userland applications.) 4 &a.spz; spz AT NetBSD.org tech-x11 There is no equivalent to the wsmouse (for mice) or wskbd (for keyboards) subsystem for graphics tablets in the generic wscons console driver framework that most NetBSD ports use. Designing and documenting the API, as well as creating at least one hardware driver and interfacing to the X server is the objective of this project. 1 &a.perry; perry AT NetBSD.org tech-userlevel The current lpr/lpd system in NetBSD is ancient, buggy, and doesn't support modern printer systems very well. Interested parties would do a from scratch rewrite of a new, modular lpr/lpd system that would support both the old lpd protocol and newer, more modern protocols like IPP, and would be able to handle modern printers easily. 5 &a.jmcneill; jmcneill AT NetBSD.org tech-embed Implement flash-translation layer to handle bad-block management/wear leveling such that a FFS or LFS file system could be placed on above NAND flash chip. 3 &a.kardel; kardel AT NetBSD.org tech-userlevel Design and implement a mechanism that allows for fast user level access to kernel time data structures for NetBSD. For certain types of small data structures the system call overhead is significant. This is especially true for frequently invoked system calls like clock_gettime(), time(), gettimeofday(). With the availability of user level readable high frequency counters it is possible to create fast implementations for precision time reading. Optimizing clock_gettime and alike will reduce the strain from applications frequently calling these system calls and improves timing information quality for applications like NTP. The implementation would be based on a to be modified version of the timecounters implementation in NetBSD. See also the Paper on Timecounters by Poul-Henning Kamp. 5 &a.wrstuden; wrstuden AT NetBSD.org &a.dillo; dillo AT NetBSD.org tech-kern The Ext2 file system is the de-facto standard, Unix-like file system used on Linux installations. Ext2 does not have journaling capabilities, so Ext3 was built on top of it to add them without breaking compatibility with Ext2. Ext3 is now a stable journaled file system used on lots of Linux installations. NetBSD currently fully supports the Ext2 file system at the kernel level. Unfortunately there is no support for the new features included in Ext3, although Ext3 file systems can be mounted provided that their journal is clean. It would be very nice if NetBSD had Ext3 file system support because the system could immediately gain a journaled file system as well as compatibility with Linux (imagine having both systems installed on a single partition!). This has, supposedly, lower risk than adding journaling to UFS because Ext3 is already heavily deployed and tested. Therefore, the aim of this project is to add Ext3 support to the NetBSD kernel accompanied by any userland code required to support it. This shouldn't be too difficult because, as we already mentioned, Ext2 is implemented in the NetBSD kernel (see src/sys/ufs/ext2fs/) and Ext3 is an extension of it. 4 &a.bouyer; bouyer AT NetBSD.org &a.tsutsui; tsutsui AT NetBSD.org tech-kern tech-userlevel NetBSD currently has support for the Ext2 file system. Unfortunately, it has some deficiencies that make its use unsuitable for a root file system, as detailed below. (Strictly speaking it can be used as such, but it is not easy to do so.) The Ext2 file system driver in the NetBSD kernel currently supports the use of this file system as the system's root. That is, / can live in an Ext2 partition. However, there is no way to natively boot NetBSD using this mechanism because there is no bootxx_ext2fs boot loader. Similarly there is no support in sysinst to install NetBSD directly onto a Ext2 partition. At the moment the only way to get this to work is to do a manual installation and later use GRUB to boot the kernel instead of the native boot blocks. But why would this be interesting? Ext2 is a very popular file system. Supporting it as root would mean that you'd install NetBSD inside the same partition as Linux (with some very minor unimplemented features). Similarly, if Ext3 support is added, NetBSD would immediately gain a journaled file system to be used for any partition. Furthermore, this eases cross-development of NetBSD from Linux operating systems. Unfortunately, there are some tricky parts in using bootxx_ext2fs even with ext2fs support in the kernel's libsa. Ext2 file systems always have their superblock stored at a 1024-byte offset from the start of the file system. This does not leave enough room to install the boot code. A workaround for this shall be found: maybe implementing bootxx_ext2fs is not really needed as long as /boot has Ext2 knowledge and its location is hardcoded in the first boot stage. (This means you will need to deal with installboot's code too.) At last, fsck_ext2fs should be improved because, after a crash, it detects (and attempts to correct!) far more errors than its Linux counterpart. It can end up destroying some data that ought to be correct in the first place because it thinks is incorrect. 7 &a.martin; martin AT NetBSD.org tech-net Samba, the SMB file server, runs fine on NetBSD as is. Since this is a very common network filesharing protocol, performance of the server should be optimized. It is probably not necessary to go all the way the NFS server code did (i.e. move most protocol handling inside the kernel). This project is about evaluating possible improvements (use of kqueue, splice/sendfile and similar concepts, adding case independent mount options for the underlying file system - probably more to be found during the project), exploring possible implementations, and benchmarking. 3 &a.martin; martin AT NetBSD.org tech-net NetBSD has a high performance PPPoE implementation (both client and server side), which runs completely inside the kernel. While this is fine for client installations, it is not practical for real server use. To solve this, a small and simple kernel modification is needed to allow a userland daemon to handle the early parts of a PPPoE session, until IPCP and/or IPv6CP are up - and then pass the complete session on to the kernel. A userland daemon needs to be implemented (or adapted), which should offer radius support. A potential extension of this project would be to improve the kernel handling of PPPoE sessions for multiple active sessions. The current design relies on only very few sessions existing (resp. pppoe device instances being configured) - and will need a review once a real server could be implemented. 7 &a.is; is AT NetBSD.org tech-kern AoE is a lightweight alternative to the complex iSCSI, albeit with little security, and limited to the local LAN. NetBSD can be used as an AoE target via aoe-vblade from pkgsrc, but an initiator is needed to retrieve the data from the target. This project is to create an initiator in the NetBSD kernel. The stretch goal is to provide a BSD-licensed (userland) AoE target as well. 5 &a.agc; agc AT NetBSD.org tech-kern The NDMP protocol specifies the protocols to perform dumps and backups across a network. There are a number of BSD-licensed XDR specs for NDMPv4, and this project is to provide the necessary functionality to take the RPC invocations and perform the work to save and present the data across the network. This backend to the NDMP protocol will allow NetBSD to act as an NDMP server for communication with third-party applications, such as Netbackup. 5 &a.matt; matt AT NetBSD.org tech-userland Currently kernels with options PAX_MPROTECT can not execute dynamically linked binaries on most RISC architectures, because the PLT format defined by the ABI of these architectures uses self-modifying code. New binutils versions have introduced a different PLT format (enabled with --secureplt) for alpha and powerpc. These two projects (one for alpha, one for powerpc) are to add support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files. Support for both the old and new formats in the same invocation will be required. 5 &a.sborrill; sborrill AT NetBSD.org &a.drochner; drochner AT NetBSD.org tech-kern Most modern web cams and other video devices with USB connections are based on the UVC device class (it is a requirement for Vista certification). This project should create kernel drivers for this device class. Defining the exact userland API, and porting at least one existing application to it is also part of this project. There are UVC drivers for OpenSolaris which, in common with Linux, use Video4Linux 2 (v4l2) as the API. This has good application support, but this does not mean it is mandatory. However, a subset of v4l2 as appropriate for the devices being supported by this project may be worthwhile. 2 &a.martin; martin AT NetBSD.org &a.joerg; joerg AT NetBSD.org tech-net The ISC DHCP client used in NetBSD is a pretty huge application, with rich and complex configurability. This is great for complex scenarios, but not needed for many others. Overall target is to create a good-enough DHCP client solution with the minimal possible footprint. 5 &a.dyoung; dyoung AT NetBSD.org tech-net Make it possible to save and restore the state of the PF packet filter to disk. The function desired is similar to &man.ipfs.8;, however, we would like the saved state to be in a human-readable form. In particular, write the PF NAT & firewall state in the format of PF rules. You will need to augment the PF rules syntax so that it can express properties of PF state such as its TTL. You need to produce a kernel interface for loading the state, and make pfctl's parser understand it. You need to make changes to the in-kernel parts of PF in order to load state. Also, provide for locking/unlocking the PF state tables as they are loaded/dumped. 7 &a.dyoung; dyoung AT NetBSD.org tech-net Create an in-kernel API for registering "packet classes" and for labeling packets with their class, for special treatment by traffic shapers (ALTQ) and by network interface drivers. With the registration part of the API, ALTQ or a driver registers the names of packet classes it recognizes. For example, ALTQ will register the 'class_name' part of a Class Command - see &man.altq.conf.5;. An Ethernet NIC with high- and low-priority transmit rings may register classes called 'hipri' and 'lopri'. An 802.11 NIC may register 802.11e traffic categories, BE, BK, VI, VO. Each registration yields a token that is suitable for labeling a packet - i.e., a small amount of data to stick in an mbuf packet header or in an m_tag. Make PF use the packet-classes API to convert PF tag names—see &man.pf.conf.5; for more about tags—to packet-class tokens, and to label mbufs with the tokens as they exit PF. Make ALTQ extract the packet-class tokens from mbufs and use them to select the packet-scheduling class. 7 &a.dyoung; dyoung AT NetBSD.org tech-kern Make NetBSD behave gracefully when a "live" USB/FireWire disk drive is accidentally detached and re-attached by, for example, creating a virtual block device that receives block-read/write commands on behalf of the underlying disk driver. This device will delegate reads and writes to the disk driver, but it will keep a list of commands that are "outstanding," that is, reads that the disk driver has not completed, and writes that have not "hit the platter," so to speak. Following disk re-attachment, the virtual block device replays its list of outstanding commands. A correct solution will not replay commands to the wrong disk if the removable was replaced instead of re-attached. Provide a character device for userland to read indications that a disk in use was abruptly detached. Open questions: Prior art? Isn't this how the Amiga worked? How will this interact with mount/unmount—is there a use-count on devices? Can you leverage "wedges" in your solution? Does any/most/all removable storage indicate reliably when a block written has actually reached the medium? 5 &a.ragge; ragge AT NetBSD.org tech-kern The NetBSD source tree contains the resize_ffs tool, which allows users to grow or shrink file systems. This tool needs a regression test suite, general code review, stability improvements and could be ported to FFS2 etc. Optional items include making it work on FFS2 file systems, or on live file systems 5 &a.reed; reed AT NetBSD.org tech-pkg pkgsrc currently has a set of tools, known as pkg_install, to install, remove and overall maintain the packages installed in a system. Unfortunately, there is no tool to do automated and safe updates of all the installed packages so, generally, this boils down to deinstalling everything in the machine to later install the new versions. As you can imagine, this is unacceptable for production machines or even desktop systems, specially if you are installing from source packages. Doing such updates from binary packages alone is slightly tolerable because they can be made quickly enough (once the binaries are already available). It is clear that we need a tool to do massive updates on a running system with minimum downtime. Recently, we added package databases to our binary repositories, as described in &man.pkg.summary.5;. These databases will make writing an update tool way easier than would be without them. The aim of this project is to provide a tool that: Retrieves one or more pkg_summary databases. Compares what is installed with what is available. Updates or installs new packages as deduced in the previous stage. The tool will have to check for conflicts and also library compatibilities when making a decision; note that this information is already available. The tool can be interactive to list what will be done and prompt user to acknowledge, but should allow automation too. The tool should also be able to just indicate what can be updated, download packages only, and search the databases. Ideally, such a tool could work both from binary and source packages, allowing the user to tune which ones to use. This could make the tool useful for all systems that do not have up-to-date binary packages available, such as slow platforms or non-NetBSD systems (as pkgsrc sees much less use on them). However, this is harder to achieve safely due to all problems that can arise when building software from sources. Therefore, the tool need not support this by the end of the SoC project, but it should be correctly designed to allow future extensions in this direction. At last, let us note that there was a pkg_install rewrite in process. The new tools have a library ready to be used from C code to handle packages. Depending on its status by the time when the project is started, the update tool might need to be built on top of this library for better integration with the new tools or simply to simplify its coding. If this is not desired at that time, it should be built around the current tools. An excellent starting point to carry on with would be the pkg_select utility that can be found in pkgsrc-wip/pkg_select, as it has lots of the requested features, but needs some cleanup. Alternatively, one may attempt to port one of the existing tools for other systems (apt-get, yum, urpmi or synaptic to mention some) and make them work with pkgsrc packages through the use of pkg_summary. The downside of this approach is that the tool could not be included in NetBSD because it would not be BSD licensed. 4 &a.reed; reed AT NetBSD.org tech-pkg In 2006 and 2007, the pkgsrc build system was abstracted to allow packaging for other package system packages. For details see pkgsrc/mk/flavor/README and the original commit message This means pkgsrc build infrastructure may be used to potentially create packages that may be installed using a non-NetBSD packaging tools (i.e. not using NetBSD's pkg_add). Note: this is not about cross-builds; the packages may be built on appropriate host system using pkgsrc collection. This project may include creating shell command wrappers to mimic pkgsrc build needs as documented in README. (The wrappers only needed for building packages and not for using packages.) Also the project may include implementing package-specific make targets as documented in README. Also see suggestions to do in the initial commit message. The goals of this project include: Add support for RPM, dpkg, SVR4, PC-BSD PBI, and/or the Solaris native package system(s). Be able to build at least 100 packages and demonstrate that the packages can be installed and deinstalled using the corresponding system's native package tools. Document support and interaction with existing packages. 3 &a.dillo; dillo AT NetBSD.org &a.dyoung; dyoung AT NetBSD.org tech-install port-mac68k port-macppc Recently, all ports but macppc and mac68k were switched from mkisofs to makefs for creation of bootable install CDs. The goal of this project is to add the missing features to makefs, so these two ports can be switched as well. If time allows, adding additional useful features would be a bonus. Needed features: Add Apple Type/Creator information to mtree spec file syntax. Create Apple Extensions to ISO9660. Merge two directory trees (mkisofs's graft points). May be needed: Create of hybrid HFS/ISO9660 image. Install HFS boot file (possibly as separate post-processing step) Additional features: Create Joliet Extensions. Print size of resulting image. 5 &a.jmmv; jmmv AT NetBSD.org tech-userlevel During the last summer of code, the Automatic Testing Framework has been created. Some tests from src/regress have been converted, but most of them are still left to do. The conversion difficulty ranges from very simple to moderately hard, but the tests need to be reviewed one by one to find the (upto now) undocumented constraints (like: needs to run as root, can not run as root, does not work on SMP machines etc.) 5 &a.joerg; joerg AT NetBSD.org &a.martin; martin AT NetBSD.org tech-net The generic Layer 2 tunnel protocol described in RFC 2661 is used in many VPN solutions. While it is possible to implement it completely in userland (and such implementations exist), for performance reasons most of the implementation should go into the kernel. This leads to a design very similar to the NetBSD in-kernel PPPoE support, which can be used as a starting point for this project. A simple client could be done completely in kernel, but to provide a scalable server side, part of the handling should be done in userland. A daemon could establish and authenticate incoming connections, then pass them on to kernel and only become involved again when the kernel notifies the daemon of unusual events (like closing the connection). This daemon could be extended to also deal with PPPoE, as a bonus, but this will not be required part of the project. 6 &a.garbled; garbled AT NetBSD.org tech-kern 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. 0 tech-kern 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. 0 tech-kern Heavily used file systems tend to spread the blocks all over the disk, especially if free space is scarce. Traditionally dump/restore have been used to recreate the file system, but this is not acceptable for current disk sizes. Since resize_ffs has to relocate blocks during shrinking anyway, it should be possible to extend it to full reordering and defragmentation. 0 tech-net Enhance zeroconfd, the Multicast DNS daemon, that was begun in NetBSD's Google Summer of Code 2005 (see work in progress: ). Develop a client library that lets a process publish mDNS records and receive asynchronous notification of new mDNS records. Adapt zeroconfd to use &man.event.3; and &man.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. 0 tech-net Add multicast DNS support to NetBSD. This would add another keyword to nsswitch.conf (mdns) and would only be valid for hosts. See also . 0 port-sgimips 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 &a.jschauma; jschauma AT NetBSD.org). See also NetBSD/sgimips. 7 port-sgimips NetBSD/sgimips currently boots on O2s with R10k (or similar) CPUs, but crashes, as soon as a DMA transfer happens. Furthermore, speculative loads are not handled correctly. This should be fixed in the kernel (not the toolchain). See also NetBSD/sgimips. 0 port-mips tech-ports 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. 0 port-sgimips 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. 0 tech-embed 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. 5 &a.oster; oster AT NetBSD.org &a.tron; tron AT NetBSD.org tech-kern NetBSD's RAIDframe disk driver &man.raid.4; currently checks the parity of a complete RAID set after an unclean shutdown. This can take several hours in case of RAID sets which span hundreds of gigabytes and will cause high I/O load on the system during that period. The cause of this problem is that RAIDframe currently uses a single bit to indicate whether or not a given RAID sets parity is known to be up-to date. On an unclean shutdown, this bit indicates that the status of the RAID set is DIRTY and that a complete check of all parity on the RAID set must be done. Similar RAID drivers for other operating systems implement a more efficient strategy for rewriting the parity. Solaris Volume Manager e.g. divides the disk into logical sections and keeps track which of these sections are out of sync. After an unclean shutdown it only rewrites the parity for all sections which are marked as out of sync. The purpose of this project is to implement a solution which reduces the amount of time required to check parity after an unclean shutdown. 3 tech-security RFC 2222 describes a very simple authentication mechanism that has been applied to various connection oriented protocols. One example is to authenticate MUAs with their outgoing mail server. This project should, at least, result in a library integrated with the in-tree postfix client to allow SASL based mail authentication. The primary design goal is a secure system, i.e. no postfix-user readable cleartext client password database. Additional integration with pkgsrc would be a bonus. Note: check dovecot and evaluate it. 7 &a.dholland; dholland AT NetBSD.org tech-userlevel System logging in NetBSD (and other Unixes) has some fairly serious shortcomings. There is no authentication of message senders (that is, any user can spoof just about any system message), no particular guarantees that messages do not get lost, and no facility for rate-limiting or otherwise preventing intentional denial-of-service. Other drawbacks can probably be identified by comparing syslogd.c with government/military requirements for logging and auditing in secure systems. The project is to, first, analyze the problem thoroughly: determine what is lacking, which of these issues can reasonably be corrected, and what system-level or kernel-level infrastructure will be required to make these corrections; then, to implement a reasonable subset of the desired corrections and provide the documentation and analysis necessary for others to undertake the remainder. 4 &a.dholland; dholland AT NetBSD.org tech-userlevel NIS is messy and insecure and unacceptable or problematic in many environments. While LDAP may be a possible alternative, in many cases a simple and tidy solution is to distribute configuration from a central machine using rdist, rsync, or a distributed change management system such as Mercurial, Git, or Monotone. Attempting to distribute all of /etc this way is problematic; in general it is better to set up a subdirectory that contains only the files that are meant to be distributed. The project is to extend libc's nsswitch mechanism to support an additional configuration source, "distfiles" (or some similar name), which reads the associated files (in the standard format) from /etc/distfiles (or some similar name), so that the latter directory can be managed with rsync and its data can be combined with regular /etc data in the same way it can when NIS is in use. 9 tech-userlevel Use puffs or refuse to write an imapfs that you can mount on /var/mail, either by writing a new one or porting the old existing Plan 9 code that does this. Note: there might be existing solutions, please check upfront and let us know. 9 &a.dholland; dholland AT NetBSD.org tech-userlevel tech-kern Figure out how to move jobs (in the job control sense) between ttys, or reconnect to your jobs after getting hung up on. This requires a fairly substantial understanding of how job control and sessions work in Unix and would probably require hacking both the tty driver and one or more shells. 2 tech-userlevel Apply statistical AI techniques to the problem of monitoring the logs of a busy system. Can one identify events of interest to a sysadmin, or events that merit closer inspection? Failing that, can one at least identify some events as routine and provide a filtered log that excludes them? Also, can one group a collection of related messages together into a single event? 7 tech-kern The policy code in the kernel that controls file caching and readahead behavior is necessarily one-size-fits-all, and the knobs available to applications to tune it, like madvise() and posix_fadvise(), are fairly blunt hammers. Furthermore, it has been shown that the overhead from user<->kernel domain crossings makes syscall-driven fine-grained policy control ineffective. Is it possible to create a BPF-like tool (that is, a small code generator with very simple and very clear safety properties) to allow safe in-kernel fine-grained policy control? Caution: this is a research project. 9 &a.dholland; dholland AT NetBSD.org tech-kern The number of pmap modules in the system is large, and most of them are substantially similar. This leads to the usual systemic ills that arise from cut and pasted code: bugs are often shared, bug fixes often don't propagate, and so forth. It should be possible to generate each pmap.c from a template and a machine description, given a suitable MMU-oriented machine description language. The project is to design and build the necessary materials. Caution: this is a research project. 5 &a.dholland; dholland AT NetBSD.org tech-toolchain Figure out what infrastructure is necessary for writing kernel components (particularly device drivers) in Cyclone. Implement it, or determine that it is not feasible, and if not, identify what the problems are and how they might be solved. 3 &a.dholland; dholland AT NetBSD.org tech-userlevel Implement real full-text search for man pages, to replace the dated and nearly useless mechanism implemented in makewhatis(8). 3 &a.dholland; dholland AT NetBSD.org tech-userlevel Put together an XML format equivalent to -mdoc, then write a bidirectional converter for man pages and a nice text-mode man browser. 3 &a.dholland; dholland AT NetBSD.org tech-userlevel Write a good text-mode browser for random XML schemas. 1 &a.dholland; dholland AT NetBSD.org tech-userlevel Extend ps to have a mode that displays jobs (at the job control level) and rolls their component processes together, much as how threads within a process are rolled together by default. 5 &a.dholland; dholland AT NetBSD.org tech-userlevel Build a backup system using erasure coding or some such foo on DVDs, so you can just add more discs over time, you only need some (smaller) number of them to restore, and so on, with the various parameters adjustable. Note: there might be existing solutions, please check upfront and let us know. 3 &a.dholland; dholland AT NetBSD.org tech-userlevel Laptops tend to not have power failures and some at least don't clear memory on reboot; can one build a ramdisk that survives reboot? 5 &a.dholland; dholland AT NetBSD.org tech-kern Add support for using a non-volatile RAM card as a buffer for the journal of a journalled file system, so the journal can be written less often and in larger chunks. 7 &a.dholland; dholland AT NetBSD.org tech-userlevel Implement full-text indexing for /home, akin to Apple's Spotlight. 5 &a.dholland; dholland AT NetBSD.org tech-userlevel Right now, if you change nameservers by editing resolv.conf, you have to kill and restart all running programs to get them to stop using the old nameserver. Figure out a clean and scalable way to get changes to resolv.conf to propagate to running processes. 1 &a.dholland; dholland AT NetBSD.org tech-userlevel Write a wiki-type tool to allow writing and maintaining parallel commentary on code. (That is, code on one side and commentary on the other, in the style of the old Lions book.) It is not immediately clear how tightly integrated this should be with cvs or cvsweb. The first step in the project is to answer this question. 7 &a.dholland; dholland AT NetBSD.org tech-toolchain Write a netpbm-style toolkit for converting and processing binary/executable formats. Since a complete such toolkit is a large project, the first step should be to identify a useful set of tools to start out with. This project could be a bottomless pit, out of scope for a summer of code. If you write a proposal, feel free to limit the range - but keep the big picture in mind! Note: evaluate FreeBSD's libelf for elf file format support. 3 &a.dholland; dholland AT NetBSD.org tech-toolchain Write a tool that combines wc(1) and cc(1). That is, a program that behaves like a compiler but instead of compiling generates accurate line counts. The idea is that you can do "env CC=wcc make" to get a line count out. Note that this is not entirely trivial because each include file should be counted exactly once and you'll need machinery for combining counts (preserving this property) at "link" time. 3 tech-kern &a.garbled; garbled AT NetBSD.org 4-5 different drivers currently share the &man.eeprom.8; program, each with a slightly different ioctl interface. Because of this, each system needs its own separate code in &man.eeprom.8;, making the entire program ugly and unwieldy. Rather, a unified interface to dealing with nvram, eeprom, and Open Firmware environment settings should be developed, preferably with proplib, and all the relevant drivers should be converted to using that. Once that is done, &man.eeprom.8; can be rewritten to no longer require nearly as much machine dependent code. 4 tech-kern 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 &man.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. 3 &a.garbled; garbled AT NetBSD.org tech-kern Many (non i386) machines used S3 graphic cards. It is one of the cards primarily found on IBM machines. Having a frambuffer driver for those cards would allow early console initialization on those machines. 3 &a.garbled; garbled AT NetBSD.org tech-kern Many (non i386) machines used Matrox G200 and similar graphic cards. Having a framebuffer driver for those cards would allow early console initialization on those machines. 3 &a.garbled; garbled AT NetBSD.org tech-kern Many ports have sysbeep/isabeep drivers, but there is little code sharing. This should be restructured and a single driver (maybe with machine dependent hooks) should be created. 5 &a.garbled; garbled AT NetBSD.org tech-kern On some machines (e.g. prep) the framebuffer can not be used by the bootloader, so we boot blind, until the kernel framebuffer driver initializes the hardware and starts output. Having something genfb(4)-like plus rasop in libsa would allow a full featured bootloader on graphical console. 7 &a.garbled; garbled AT NetBSD.org tech-kern Add support for SMP to port prep. This project requires access to the necessary hardware (7025-F40 or MTX604) 8 &a.dyoung; dyoung@NetBSD.org tech-userlevel Produce a suite of simple command-line utilities that act on XML files as grep(1), sed(1), and join(1) act on plain text files. For example, xmlgrep(1) may select contents of an XML file by XPath-like language, regular expression, or both; it may emit either a well-formed subset of the XML input, or plaintext. 6 &a.dyoung; dyoung@NetBSD.org Produce a boot image for a system with no more than 4MB Flash / 16MB RAM, run a useful NetBSD router with DHCP client/server, IPv6 route solicitation/advertisement, PPPoE, and an 802.11a/b/g WPA access point. Your image must be replicable: using only the NetBSD sources, the 3rd-party sources you select, and your scripts and Makefiles, a developer should be able to cross-build your system boot image. 6 &a.dyoung; dyoung@NetBSD.org tech-embed Produce lessons and a list of affordable parts and free software that NetBSD hobbyists can use to teach themselves JTAG. Write your lessons for a low-cost embedded system or expansion board that NetBSD already supports. 7 &a.dyoung; dyoung@NetBSD.org tech-kern Write a block device driver the NAND Flash on a low-cost embedded board that NetBSD supports—e.g., RouterBOARD 153. Show that you can erase blocks on the flash, write NetBSD to the flash, and boot NetBSD with root on flash. When you finish your first driver, write a driver for a second NAND part, and extract common code for reuse in the driver after that. 9 &a.dyoung; dyoung@NetBSD.org tech-kern Replace the machine-dependent, ad-hoc mechanisms for allocating physical address space in NetBSD with a machine-independent address-space manager. 9 &a.dyoung; dyoung@NetBSD.org tech-kern CardBus is essentially a hotpluggable PCI bus in a compact form-factor, but in NetBSD, there are independent CardBus and PCI bus back-ends. The back-ends replicate a lot of code, and many drivers have very similar bus front-ends both for PCI and for CardBus. Introduce both dynamic management of PCI bus resources (memory and I/O address space, interrupts) and insertion/ejection-event handling to the PCI bus back-end. Use the PCI bus back-end to replace the CardBus back-end. If time allows, use your PCI bus back-end improvements to support ExpressCard. 9 &a.dyoung; dyoung@NetBSD.org Do something useful and cool with the Dragon FPGA board. For example, demonstrate a PCI bus master that computes some useful function (encryption, signal processing, neural network) for the NetBSD host, or a PCI bus analyzer controlled by a NetBSD character device. Each component of your product, including the VHDL, should be open source. 8 &a.dyoung; dyoung@NetBSD.org tech-net bridge(4) is a software implementation of an ethernet bridge. It copies packets from each member interface to one or more of the other member interfaces. In order to do this, it puts each member interface into promiscuous mode, inspects each received packet's ethernet header to determine its destination port, and retransmits each packet. This entails a lot of CPU overhead, especially at high packet rates. NetBSD runs on the Infineon ADM5120, a MIPS system on a chip that has a built-in, 6-port ethernet switch. The host processor controls a matrix of interconnections between ports that lets it either isolate each port, or connect it with up to five of its neighbors and the CPU to form a virtual LAN. bridge(4) could exploit this matrix to offload a lot of its work from the CPU to the ADM5120's built-in switch. Design an interface between bridge(4) and its member interfaces for the bridge to tell each interface about the bridge's membership and configuration, so that each driver can offload the bridge's work to hardware. Extend admsw(4) to use the ADM5120's switch. 7 &a.dyoung; dyoung@NetBSD.org tech-toolchain tech-userlevel Add to build.sh the ability to build boot images for a NetBSD-based appliance such as a firewall, a file server, or a wireless router. In addition to building a NetBSD kernel and distribution, build.sh needs to: Install the system to a staging area. Cross-build and install 3rd-party application software. Filter extraneous files from the METALOG. Install groups and users. Install application-specific rc.conf(5), scripts, data and configuration files. Create a bootable FFS/ISO9660 image with makefs(8), disklabel(8), fdisk(8), installboot(8); a Network File System archive; or a kernel with memory-disk root. A single specifications file should tell build.sh everything it needs to know to build an appliance boot image. Ideally, your successful completion of this project will incite development of spec files for several useful appliances! Look closely at CUWiN's scripts for cross-building NetBSD-based boot images for a wireless mesh router, and borrow freely. The scripts represent more than five years' experience with cross-building NetBSD appliances, and they provide most of the above-mentioned functions. The scripts are not integrated with build.sh, however, and they do not support a spec file. 8 &a.aymeric; aymeric AT NetBSD.org tech-kern The GNU project's operating system HURD is not yet exactly ready for comfortable use. However, it introduces the interesting concept of translators, which generalize the notion of "mount point". Enabling to use HURD tranlators within NetBSD could provide added functionality for users of NetBSD as well as a stable and efficient platform for developers of HURD translators. The project touches several aspects of the kernel: File system modifications: support for settrans/showtrans in ext2fs and ufs, fsck changes to accomodate for the presence of translators Virtual file system modifications: adding the concept of passive/active translator, enabling the mounting of a translator on any vnode, not just a directory (Writing one very basic native translator) Binary emulation of GNUMach executables to the point where a few native useful translators can be run The last point is probably very long, but can be done progressively. The second point is strategic because it will prove the concept's validity and will guarantee the success of the project in the long run. 3 &a.pooka; pooka AT NetBSD.org tech-userlevel The mtools project provides command line tools for accessing FAT file system images without having to mount the file system. However, it duplicates a lot of equivalent code which already exists in a kernel file system and therefore misses out on synergy benefits, e.g. more testing for the same code. NetBSD provides support for running kernel file system code in userland via the Runnable Userspace Meta Program functionality. By using the libukfs library, it is possible to access file system images directly in userspace without having to mount the file system image. This can be used to implement mtools-like functionality for any file system supported by the NetBSD kernel. To the best of our knowledge, functionality to be implemented in this project is not available in any mainstream OS. The project consists of the following tasks: Design and implement a set of tools for file system access. Usage examples are: rdir ffs ~/ffs.img /bin, which would list the "/bin" directory of an ffs image, rcat efs ~/efs.img /etc/passwd which would display the contents of "/etc/passwd" on an efs image, and rrmdir msdos /dev/rwd1a /nukeme would remove the directory "nukeme" from an msdosfs file system on wd1a. Additionally, if there is time left, implement the same functionality as a command console similar to e.g. fsdb. Since this allows to retain state across different file system requests, it could provide extra features not possible with standalone command line tools. This and the command line utilities should either share a common backend, or the command line utilities can be implemented as a frontend to the command console. Implement a test suite for regression testing of the utilities created in the project. For extra credit, verify that the created utilities are buildable and work on non-NetBSD platforms. NetBSD kernel file systems have already been run in userspace on non-NetBSD platforms, so this is known to be possible. To get an idea of how to proceed with the implementation, the very unfinished fsconsole can be studied along with the ukfs library programming interface. mtools can also be studied for inspiration. This focal point of this project is producing tools with good usability. Even though kernel file system code will be used, this project will be implemented entirely in userspace and there is no need to understand kernel file system code. In a very very distant future the above toolset could be integrated with standard POSIX.1 command line utilities, e.g. ls and mknod. But since this requires huge changes to e.g. how system calls are handled, how mount points are handled, and what the OS treats as a service, it is most definitely outside the scope of a SoC project. This is mentioned just to point out that there are plenty of future research opportunities for interested students familiar with the problem area. 8 &a.dyoung; dyoung AT NetBSD.org &a.pooka; pooka AT NetBSD.org tech-userlevel The makefs utility creates a file system image from a given directory tree. For ffs, it is currently implemented using specially modified kernel code to populate the file system image. The goal of this project is to convert makefs to use vanilla kernel file system code with the help of the Runnable Userspace Meta Program framework and the ukfs library. This will reduce code duplication and will also provide the option to support any kernel file system with write support. The project's work areas are two-faceted: they involve both the build framework and file system creation: Figure out how to get librump and the relevant file system libraries compiled as part of the tool build. This involves most likely making them shared libraries, which involves figuring out how to flag ABI incompatibilities (tag the library with the kernel version?). It also involves figuring out how to install the same libraries as part of the base system. Test and make sure that the resulting code runs at least on NetBSD, FreeBSD and some Linux distributions. The NetBSD kernel file system code has been run in userspace on Linux with ukfs before, but support has likely bitrotted. Implement support for file system creation for at least FAT. Convert ffs to use the vanilla kernel ffs code and ukfs instead of handcrafted code. Add equivalent support for at least FAT. The project will be implemented entirely in userspace. While file system knowledge is a requirement for creating empty file systems, handling kernel file system code is not a requirement. The student should have a good understanding about the build framework. 6 &a.dyoung; dyoung AT NetBSD.org tech-net Create an add-on for Wireshark that reads a trace of 802.11 packets with radiotap headers, and renders each packet as a trapezoid on a timeline, like this: Place the left edge of a trapezoid to represent a packet's time of arrival. Set the length of the top or bottom edge in proportion to transmit duration. Use other display properties of the trapezoid such as shear, hue, saturation, height, texture, and top-edge width to express packet properties such as signal strength, bitrate, type (management, data, control), MAC, and BSSID. In 2003, a student team worked on the visualizer. They did not produce a finished product, but their report on Argos may help you. While you design and code the display add-on, keep in mind both the important 802.11 transactions, such as (RTS/CTS/)Data/Ack, and export to SVG, PDF, or PostScript for reproduction on the WWW or in print. 7 &a.pooka; pooka AT NetBSD.org tech-userlevel File systems are historically mounted by specifying which type of file system is mounted from where (e.g. mount -t ffs /dev/wd0a /mnt). However, sometimes a user is only interested in making the data available and not particularly interested in how or from where it is made available. This project investigates the first steps in turning file systems into network-transparent services by making it possible to mount any kernel file system type from any location on the network. The file system components to be used are puffs and rump. puffs is used to forward local file system requests from the kernel to userspace and rump is used to facilitate running the kernel file system in userspace as a service daemon. The subtasks are the following: Write the necessary code to be able to forward requests from one source to another. This involves most likely reworking a bit of the libpuffs option parsing code and creating an puffs client, say, mount_puffs to be able to forward requests from one location to another. The puffs protocol should be extended to include the necessary new features or another protocol defined. Proof-on-concept code for this has already been written. Currently the puffs protocol used for communication between the kernel and userland is machine dependent. To facilitate forwarding the protocol to remote hosts, a machine independent version must be specified. To be able to handle multiple clients, the file systems must be converted to daemons instead of being utilities. This will also, in the case of kernel file system servers, include adding locking to the communication protocol. The end result will look something like this: # start serving ffs from /dev/wd0a on port 12675 onehost> ffs_serv -p 12675 /dev/wd0a # start serving cd9660 from /dev/cd0a on port 12676 onehost> cd9660_serv -p 12675 /dev/cd0a # meanwhile in outer space, mount anotherhost from port 12675 anotherhost> mount_puffs -t tcp onehost:12675 /mnt anotherhost> mount ... anotherhost:12675 on /mnt type <negotiated> ... anotherhost> cd /mnt anotherhost> ls ... etc The student should have some familiarity with file systems and network services. The application should include an answer to the following question: "how is this different from nfs?" 5 &a.garbled; root AT garbled.net tech-install Sysinst is the current installer for NetBSD. Currently, the installer is an interactive process, where it asks you questions, and acts immediately on those answers. Sysinst should instead be broken into two components. A front end, which asks a number of questions about the install, such as disk layout, machine name, etc, and a back end, which does the actual installation. The front end, should create an installation configuration file, which would describe the installation to be performed to the back end. This configuration file should be flexible enough, that it can be hand-edited to contain things such as "swap should be 10% of the disk, or at least 128MB". In this way, a default configuration could be shipped, which would allow the user to simply bypass the front end, and run the back end. The back end would do all the actual work of the installation, taking it's cues from the description file. With a flexible enough configuration file, it would be possible to build a kickstart/jumpstart like system by supplying config files and executing them via the backend. 7 &a.ober; ober AT NetBSD.org tech-net OpenAFS currently exists in pkgsrc for the server portion. Client support would require fixing the legacy NetBSD client support. Updates would need to either make use of the new LKM interface or possibly PUFFS.