The FreeBSD Project is excited to take part in the Google Summer of Code 2006. This project endeavors to fund students to contribute to an open source project over the summer break.

• Student Projects
• Example Proposal Ideas
  • Userland / Installation Tools
  • Filesystem
  • Networking
  • Security
  • Kernel
• Possible Mentors
• Proposal Guidelines
• Infrastructure Provided to Students
• Frequently Asked Questions

Student Projects

See also Wiki and Google pages.

Example Proposal Ideas

In addition to the student project ideas listed below, the FreeBSD Project maintains a list of general projects looking for volunteers here.

Userland / Installation Tools

• Bundled PXE Installer: It would be great to have a bundled PXE installer. This would allow one to boot an install server from a FreeSBIE live CDROM on one box, set the BIOS on subsequent boxes to PXE boot, and then have the rest happen by magic. This would be very helpful for installing cluster nodes, etc.
• Fully Integrated SNMP monitoring: Plugins for our BSNMP pieces to monitor elements of system state such as load, disk space, VM statistics, entropy, firewall rules and states, sendmail queues and accepts/rejects, and the like. An SNMP client that could pull and centralize the data gathering, render it, etc. &a.philip;, &a.glebius;, &a.harti;, and &a.rwatson; are coordinating.
• Integrate Xen Support: Support for the Xen virtual machine monitor is coming into FreeBSD -CURRENT, so the installer could be updated to make it possible to setup a Xen system with several FreeBSD nodes, etc. Please coordinate with &a.kmacy; who has done work in this area.
• Improve our regression testing system: Nik Clayton has written a regression test infrastructure using Perl. More of the regression tests should be made to work with libtap. There are two main parts to it. First, many of the existing tests should be moved from using assert() to using ok() and friends from libtap. Second, more regression tests should be written. Students familiar with scripting languages and software testing are encouraged to work on this. &a.nik; is the coordinator.
• Tracking performance over time: One of the major issues in a project the size of FreeBSD is monitoring changes in performance characteristics over time. Doing this requires several things. Those include a suite of appropriate tests, hardware to run the tests on, a database to store results in, and software to extract interesting results and display them. Solving the whole problems is probably beyond the scope of one summer's work, but an interesting subset should be manageable. &a.brooks; is the coordinator.
• Improvements to FreeBSD's userland profiling: There are a number of enhancements possible to FreeBSD profiling infrastructure: (a) allowing the profiling clock used by executables compiled for profiling to be driven by hardware performance monitoring counters, (b) enhancing gprof(1) to profile dynamically linked executables, and (c) making gprof(1) and moncontrol(3) to be architecture independent. &a.jkoshy; is the coordinator.
• A GUI front end for hwpmc(4): Create a GUI tool that can collect performance data using hwpmc(4) and display it visually. In brief such a tool would offer: live and offline analysis of a hwpmc(4) data stream, visual indication of hotspots in executables and shared libraries with the ability to drill down to an annotated source or machine code listing, system-wide as well as process-specific analyses, visual representations of callgraphs. &a.jkoshy; is the coordinator.
• BSD licensed API compatible version of GNU readline: Create a cleanroom implementation that is API compatible with GNU readline but which is not encumbered by the GPL. &a.jkh; is the coordinator.

Filesystem

• inode versioning: Introduce an inode version number into UFS, so we can store inodes in different formats. As an example of how to use this, introduce a new inode format that has a 32 bit link count field. &a.dwmalone; is the coordinator.
• Autofs: Create the autofs filesystem from a specification. Candidates should have some filesystem knowledge and network filesystem knowledge. Kernel transport and interaction with the "amd" automounter needs to be completed. &a.alfred; is coordinating.
• Logical Volume Manager

Networking

• IPv6 stack vulnerabilities: Review the last few years worth of IP stack vulnerabilities. Check that these have been fixed in the IPv6 stack too. Fix ones that haven't been fixed. &a.dwmalone; is the coordinator.
• IPv6 feature parity: Review new features that have been added to the IP stack (hostcache, TCP MD5 checksums, ...). Check if these include IPv6 support. Implement if it hasn't. &a.dwmalone; is the coordinator.
• NFS Lockd (improve semantics): Improve the semantics of the NFS lockd in FreeBSD. Apple has made certain enhancements that can be leveraged in our code base. Implement state recovery in the lockd. Candidate would learn how to port code from one kernel to another as well as how to maintain state on the client side. This would be a good resume addition. &a.alfred; is coordinating.
• NFS Lockd (kernel implementation): Improve the semantics of the NFS lockd in FreeBSD. Moving the lockd implementation into the kernel provides several key performance and semantic improvements. Candidates should have a good understanding of NFS, locking, RPC and kernel networking. This is a great resume addition, providing you want to be saddled with "knowing NFS" for the rest of your career, it is not for the faint of heart. &a.alfred; is coordinating.

Security

• SecureMines: Add meta-data to the system in order to trap intruders and provide an audit log. The goal of this project is to create several means of marking an event as a foreign act (such as opening a trap file) which halts the system and provides as much information as possible, possibilities include using extended attributes to tag such "mines". Candidates should have an understanding of the Unix process model and should be prepared to investigate the new comprehensive audit system in FreeBSD. This system will shortly have a framework for writing intrusion detection modules. &a.alfred; and &a.rwatson; are coordinating.
• SEBSD: SEBSD is a port of NSA's SELinux FLASK/TE security model to the FreeBSD operating system using the TrustedBSD MAC Framework. Right now the system is highly experimental, and a great project would be for one or more students to spend the summer taking it from an experimental prototype to something that can be actually used. This might include the development of policy, integration of SEBSD into the installer components, adaptation of userland components, sample deployments, documentation, and so on. Candidates will want some background in access control technology, especially mandatory access control; experience with alternative security models would be a plus, as would a background in OS development. However, there's room for a range of work here, and all proposals will be considered! &a.rwatson; is coordinating.
• Audit: Audit is a fine-grained security event log mechanism present in FreeBSD (and other operating systems). FreeBSD's audit implementation is based on Sun's published BSM API and file format, and will appear in FreeBSD 6.2-RELEASE. A variety of student projects are available to work on, including tasks such as working on XML output support and database integration, a graphical audit review tool, distributed audit log management support, and intrusion detection work. Students are encouraged to contact &a.rwatson; who is coordinating.

Kernel

• Generic Input Device Subsystem: Some work has been done in Perforce that begins to replace the ancient psm->moused->syscons codepath into something more pleasant. There's still a lot of duplication between psm and moused, however and even more work is necessary to get syscons to be happy with the new world order. &a.philip; is coordinating.
• Update the Linuxulator: FreeBSD provides Linux binary compatibility through a Linux system call table that is invoked when Linux ELF binaries are executed. This implementation should be compared with an up-to-date Linux Kernel so that important missing syscalls can be added to ensure that all mainstream applications continue to work on FreeBSD. The student should be able to read and understand foreign C code, write C code, and have a good understanding of how to do a clean room implementation of GPLed code (no copy & paste!).
• Suspend to disk: Implement a suspend/resume from disk mechanism. Possibly use the dump functions to dump pages to disk, then use ACPI to put the system in S4 or power-off. Resume would require changes to the loader to load the memory image directly and then begin executing again. This project requires good knowledge of C, an understanding of the hardware/software interface, a laptop that works with ACPI, and kernel awareness. &a.njl; and &a.bruno; are coordinating.
• Implement and profile various algorithms for powerd(8): Implement a range of predictive algorithms (and perhaps design your own) and profile them for power usage and performance loss. The best algorithm will save the most power while losing the least performance. Requires basic C knowledge, laptop supported by cpufreq(4) (suggest newer Pentium-M CPU), and some statistics. &a.njl; and &a.bruno; are coordinating.
• Kernel meta-language: Develop a dialect of the C language that simplifies the task of writing kernel code. It should include language extensions that make it possible to write kernel code more cleanly and with less bugs. An example of this would have language support for linked lists, to obviate the need for messy MACROs. &a.gnn; and &a.phk; are coordinating. A Wiki with more information is available here.
• The Arbitrary Interpreter Hack: Allow FreeBSD binaries for non-native CPU architectures to be emulated by having these 'interpreted' by an instruction set emulator. This work would allow FreeBSD/{ARM,MIPS,PowerPC} executables to run on a FreeBSD/i386 or FreeBSD/amd64 host. This project requires an in-depth study of machine ABIs and of Unix semantics. It has a small kernel component and also involves effort in making the instruction set emulator robust. &a.jkoshy; is the coordinator.
• Cheap Syscalls: Add a page shared between every process and the kernel to do things like gettimeofday() without doing a real syscall. Can also be used to enable the use of SYSENTER to do other syscalls, on i386, when the hardware supports it. Similar to Linux's vsyscall page. Requires good knowledge of C, memory management on modern operating systems, and run-time linking. &a.ssouhlal; is the coordinator.
• Boot-time Kernel Patching: Design and implement an API to patch kernel code based on hardware features detected at boot. This will, for example, enable the use of PREFETCH instructions when 3DNow! support is detected on the CPU. Requires good knowledge of C, and basic knowledge of i386 assembly. &a.ssouhlal; is the coordinator.
• NMI Watchdog: Use the performance counters feature of i386/amd64 processors to periodically send an NMI to every processor, and make sure the kernel is still running correctly. Requires good knowledge of the i386 architecture and C. &a.ssouhlal; is the coordinator.

Additional projects may be found by browsing the FreeBSD Development Projects page or by viewing some of the recent Developer Status Reports.

Mentors

If you are interested in working on a project not explicitly mentioned above, you may want to contact one of the potential mentors below about writing a proposal in one of the following broad categories.

• Networking: &a.alfred;, &a.gnn;, &a.brooks;, and &a.sam;
• Filesystems: &a.scottl;, &a.alfred;, &a.ssouhlal;
• GEOM: &a.phk;
• Release Engineering / Integration: re@FreeBSD.org
• TrustedBSD / Security: &a.rwatson;
• Pluggable Disk Schedulers: &a.luigi;.
• ACPI: &a.njl; and &a.bruno;.
• Sound: &a.matk;.
• Virtual Memory: &a.ssouhlal;.
• Performance Monitoring: &a.jkoshy;.
• Ports Collection: &a.erwin;.

If your project is not selected for funding by Google, but you still think you have a feasible project proposal, then please email proposals@FreeBSD.org.

Proposal Guidelines

Students are responsible for writing a proposal and submitting it to Google before the application deadline. The following outline was adapted from the Perl Foundation open source proposal HOWTO. A strong proposal will include:

• Name
• Email
• Project Title
• Possible Mentor (optional)
• Benefits to the FreeBSD Community - a good project will not just be fun to work on, but also generally useful to others.
• Deliverables - It is very important to list quantifiable results here e.g.
  • "Improve X modules in ways Y and Z."
  • "Write 3 new man pages for the new interfaces."
  • "Improve test coverage by writing X more unit/regression tests."
  • "Improve performance in FOO by X%."
• Project Schedule - How long will the project take? When can you begin work?
• Availability - How many hours per week can you spend working on this? What other obligations do you have this summer?
• Bio - Who are you? What makes you the best person to work on this project?

Infrastructure Provided to Students

In 2005, the FreeBSD Project provided access to the FreeBSD Perforce revision control infrastructure in order to facilitate student collaboration, provide public access and archiving for the on-going student projects, and to help mentors and the community monitor on-going work. It is expected that students participating in the 2006 program will be offered the same facilities, and that unless there is a strong argument otherwise, that those facilities will be used for 2006 projects. Students will also be asked to maintain wiki pages on their on-going projects. In the past, e-mail, IRC, and instant messaging have proven popular among students and mentors, and students participating in the FreeBSD summer program are encouraged to use these and other electronic communication mechanisms to become active in the community.

Frequently Asked Questions

• Am I eligible?

  Please see the Google Student FAQ for all questions about eligibility.

• When is the proposal deadline?

  May 8, 2006 17:00 Pacific Daylight Time. Proposals must be submitted through the Google web site, not directly to the FreeBSD Project.

• Where do I send my proposal?

  Propopsals must be sent to Google's student signup page.

• What projects were completed successfully by students last summer?

  Please see the 2005 FreeBSD Summer of Code page for a list of the completed projects from last year.