FreeBSD Google Summer of Code Ideas
Below are ideas for FreeBSD GSoC, which the FreeBSD community have suggested. They fit roughly into the GSoC timelines, but Summer of Code applicants should contact idea owners or suitable mentors early so that they can get feedback during the application process. We want to ensure that projects can be completed within one of the GSoC timeframes.
These are only suggestions; copy/pasting the text in your proposal doesn't guarantee we will accept it. You can propose ANY FreeBSD-related idea/project you want but we want to see that you have researched the project and that you have a clear plan. We like original ideas, since we know you'll be most interested in working on something you came up with and are passionate about. Starting in 2022, there is more flexibility with project timelines, but a clear schedule of project milestones is still essential for success.
For projects where no mentor is listed, or for project proposals created by applicants, we recommend that you try to contact committers working in the area and discuss the project with them. If you are unsure who to contact, reach out to us by one of these methods.
Join the #freebsd-soc IRC channel on the Libera.Chat network. We use this channel for communication during both the application period and the coding period. Due to timezone differences, there may be delays before questions are answered, so please be patient. You can join the channel either using an IRC client like irssi, or using Libera.Chat's web client. You can read about how to connect to the Libera.Chat network.
Email the freebsd-hackers@FreeBSD.org mailing list.
If you do not get a response on IRC or on the mailing list, you can email soc-admin@FreeBSD.org.
We also have a generic FreeBSD ideas page at IdeasPage and WantedPorts. Note that many of these may not be suitable Summer of Code projects as-is, but may provide inspiration for ideas of your own. The projects listed on this page are not restricted to GSoC participants, of course.
For a feel for projects from previous years, visit: SummerOfCode2021, SummerOfCode2020, SummerOfCode2019, SummerOfCode2018, SummerOfCode2017, SummerOfCode2016, SummerOfCode2015, SummerOfCode2014, SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010.
Contents
- FreeBSD Google Summer of Code Ideas
-
Ideas list
-
Kernel Projects
- Unified kernel tracing interface
- Convert all FDT drivers attachments to be table driven and mark with PNP_INFO
- bhyve debug server enhancements
- Command Line Editing, history and escape completion in Boot Loader
- Add audit(4) support to NFS
- Port squashfuse to the FreeBSD kernel
- Complete FreeBSD's MPLS implementation
- Linuxulator on powerpc64
- Implement Netlink (RFC 3549) kernel support
- Add support for building Linux-only network drivers
-
Userland projects
- ELFToolChain improvements
- Kernel LLDB debugger module support and integration
- UFS4fuse: support FreeBSD's UFS2 with fusefs
- syzkaller improvements
- Move to GENERIC armv7 distribution scripting
- Move to GENERIC armv7 distribution web interface
- Capsicumization of the base system
- Network Configuration Libraries
- Audit Base for Read-Only and NFS Mount Compatibility
- PJDFSTest rewrite
- Build infrastructure
-
Kernel Projects
How to use this idea list
For applicants
- The list of projects here should be regarded as inspiration, not as the exclusive list of all projects that will be considered. We are happy to try to find mentors for projects that will benefit the FreeBSD project. If you're unsure if your idea fits this description, try asking in #freebsd-soc on Libera.Chat or #bsddev on EFNet.
- You should propose the design of your idea first, and only start coding once your project is accepted. Producing a decent design will save you lots of effort.
- Most mentors are working professionals. Please use their time effectively, with up-front study of issues and problems, and try to provide as much data as possible.
We have a page at SummerOfCodeDevEnvironments where we detail some possible ideas for how to set up your developer environment.
We also have several pieces of advice on applying at SummerOfCodeStudentChecklist
Skill levels
In 2022, GSoC projects can be 175 or 350-hour projects with the ability to extend the program from the standard 12 weeks to 22 weeks. Choose a project that you feel you can realistically complete within one of those timelines. If you feel unsure, please contact the listed mentor(s) to get their opinion on how much effort and experience a given project may require.
C: For C-related ideas, at least some experience coding in C is necessary. Generally, it is easier to program/debug userland software than it is when working on the kernel. Kernel programming/debugging is harder, and can involve skills ranging from understanding internals of operating systems construction to understanding the computer architecture itself.
Kernel: The FreeBSD kernel is written in C, so at least a basic proficiency in C is required to choose a kernel project. Various levels of other skills may be necessary, but you can certainly assume that knowing how to do "Hello world" in the kernel and knowing how to recompile the kernel should be an essential starting point.
Network: Understanding of TCP/IP will be required for these projects. It'd be good if you understood socket API for any programming language, and know stuff like "sockets".
Security: For these tasks you must have general understanding of security issues, UNIX permission model, basics of cryptography and its applications.
Scripting: For scripting, unless otherwise stated we won't enforce which language you choose, however there are certain factors for this choice: if you're willing to work with /bin/sh (+awk/sed/etc), there is a higher chance that whatever you produce could be committed to the base system. If you pick something like bash, which we don't include in the base system, it may still be possible to create a convincing case for the tool to get into the tree, with some level of commitment and convincing. For other things in languages too large for the base system and not present there (e.g.: perl, python, ruby), these can still be offered as useful tools to others, but (e.g.) these would be bad language choices for things that need to be usable with just the base system (e.g. the installer). Tools are equally important as every part of the OS. If you create a tool for debugging, analyzing and visualizing complex data, it might help dozens of FreeBSD hackers around the world to be 10x more productive.
Ideas list
Kernel Projects
Unified kernel tracing interface
Mentor |
Mark Johnston <markj AT FreeBSD DOT org> |
Skills |
C (advanced), Kernel |
Mid-term deliverable |
Implementation available for amd64 |
Duration |
350 hours |
Difficulty |
Hard |
Expected Outcome |
Existing consumers converted to use the new interface |
Description
The FreeBSD kernel contains several subsystems which add hooks to core pieces of the kernel. For example, the context switch code in the scheduler contains this snippet:
if (td != newtd) { #ifdef HWPMC_HOOKS if (PMC_PROC_IS_USING_PMCS(td->td_proc)) PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_OUT); #endif SDT_PROBE2(sched, , , off__cpu, newtd, newtd->td_proc); #ifdef KDTRACE_HOOKS /* * If DTrace has set the active vtime enum to anything * other than INACTIVE (0), then it should have set the * function to call. */ if (dtrace_vtime_active) (*dtrace_vtime_switch_func)(newtd); #endif td->td_oncpu = NOCPU; cpu_switch(td, newtd, mtx); cpuid = td->td_oncpu = PCPU_GET(cpuid); SDT_PROBE0(sched, , , on__cpu); #ifdef HWPMC_HOOKS if (PMC_PROC_IS_USING_PMCS(td->td_proc)) PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_IN); #endif
There are three hooks that may be called before switching into the new thread, and two hooks that may be called after the switch. They are used by DTrace and HWPMC to collect information about context switch events. These hooks are disabled most of the time, but each hook introduces overhead even when disabled since we must check whether it is enabled each time the code is executed.
The goal of the project is to identify useful kernel tracepoints, and design and implement a unified interface that can be used by different consumers to collect information about the event corresponding to a particular tracepoint. This would make it easier for new subsystems to collect information from existing tracepoints, rather than modifying the core kernel to add more hooks. An additional aim would be to ensure that such tracepoints have minimal overhead, probably by using hot-patching to enable and disable a particular tracepoint. FreeBSD-CURRENT now uses clang 10.0, which implements the "asm goto" construct that could be useful here.
Convert all FDT drivers attachments to be table driven and mark with PNP_INFO
Mentor |
Warner Losh <imp AT FreeBSD DOT org> |
Skills |
C (intermediate), knowledge of kernel build a plus |
Mid-term deliverable |
First 2/3 of drivers converted, preliminary GENERIC pruning for 1 board that boots with drivers loading |
Duration |
350 hours |
Difficulty |
Medium |
Expected Outcome |
All drivers converted, armv7 GENERIC pruned, booting on multiple boards with drivers loading at boot as needed |
Description
The devmatch infrastructure gives us a way to match up hardware with kernel modules that implement drivers that claim the hardware. One problem, however, is that these drivers need some modification before devmatch can use them. Specifically, they need to have their compatibility scans done via a table, and that table needs to be decorated with a PNP_INFO tag so the compiler and kld_xref extract the metadata that devmatch needs to do its job. In addition, the armv7 GENERIC kernel needs to be trimmed of the drivers that can be loaded like this. Three different boards from different SoC families have to successfully boot with their drivers that can be loaded automatically.
bhyve debug server enhancements
Mentor |
John Baldwin <jhb AT FreeBSD DOT org> |
Skills |
C (advanced), kernel programming (advanced) |
Duration |
175 hours |
Difficulty |
Hard |
Expected Outcome |
Support added for single-Stepping on AMD systems and support for hardware watchpoints |
Description
With r333140 bhyve implements a debug server, allowing debuggers that speak the GDB protocol to inspect guest state. r355724 extended the debug server to support the setting of breakpoints. Some more features that would be useful:
* The breakpoint implementation uses an Intel-specific feature, the Monitor Trap Flag, to perform single-stepping, but this does not work on AMD systems. It should be possible to make use of the RFLAGS.TF flag to perform single-stepping if the monitor trap flag is not implemented. Note that this could be implemented and tested on Intel systems by disabling the use of monitor traps in the debug server.
* Implement support for hardware watchpoints. In particular, modify the debug server to set debug registers in the guest and handle VM exits due to debugging exceptions. Some care would be needed to avoid clobbering guest state if the guest OS is making use of hardware debug registers.
Note: these projects require familiarity with at least the basics of how debuggers and hardware-assisted hypervisors work.
Command Line Editing, history and escape completion in Boot Loader
Mentors |
Warner Losh <imp AT FreeBSD DOT org> |
Skills |
C (intermediate) and Lua (intermediate) |
Duration |
175 Hours |
Difficulty |
Medium |
Expected Outcome |
Boot loader prompt that supports command line editing and history |
The current boot loader lacks any kind of command history and editing. This is because it was designed to be small. Now that UEFI has greatly expanded the limits, it makes sense to bring in functionality like this. This effort would involve creating a number of primitives for expansion, storing the history, etc. It would likely also require some lua integration to work. This project is one that has a lot of sub-parts, some of which may be omitted (eg command history w/o filename completion) and still result in good project.
Add audit(4) support to NFS
Mentor |
Rick Macklem rmacklem@FreeBSD.org |
Skills |
C (intermediate), Kernel (intermediate), Security (intermediate) |
Mid-term deliverable |
Ability to generate an audit trail for any NFSv3 RPC |
Duration |
350 hours |
Difficulty |
Medium |
Expected Outcome |
Ability to generate an audit trail for any NFS RPCs |
Description
Security Event Audit is a facility to provide fine-grained, configurable logging of security-relevant events, and is intended to meet the requirements of the Common Criteria (CC) Common Access Protection Profile (CAPP) evaluation. It can record an audit record for various events, such as process creation, network activity, or file system activity. However, it mostly works at the syscall level. Since the NFS server is implemented within the kernel, that means NFS RPCs don't generate any audit records. audit(4) can still be used within NFS networks, but auditd must be run on every NFS client. It would be a great addition if each NFS RPC could be audited. That would allow auditd(8) to run just on the NFS server, and still audit all NFS activity within the network.
Port squashfuse to the FreeBSD kernel
Mentor |
Ed Maste <emaste AT FreeBSD DOT org> |
Skills |
C (expert), fusefs (expert), kernel |
Mid-term deliverable |
Basic squashfs.ko functionality available with mount(8) |
Duration |
350 Hours |
Difficulty |
Hard |
Expected Outcome |
MFSBSD support |
Description
squashfs is a read-only filesystem targeted for small embedded environments, where memory and disk space is constrained. squashfuse is a BSD-licensed FUSE implementation of squashfs. The project would be to port this implementation to the FreeBSD kernel, with the aim of being able to boot FreeBSD from an in-memory squashfs filesystem.
Complete FreeBSD's MPLS implementation
Mentor |
George V. Neville-Neil gnn@FreeBSD.org |
Skills |
C (intermediate), networking (intermediate) |
Mid-term deliverable |
|
Duration |
350 hours |
Difficulty |
Medium |
Expected Outcome |
Full integration with net/frr LDP daemon and/or net/bird |
Description
Multiprotocol Label Switching (MPLS) is data forwarding technology that increases the speed and controls the flow of network traffic. With MPLS, data is directed through a path via labels instead of requiring complex lookups in a routing table at every stop. There has been work to add the MPLS stack to FreeBSD, but none are complete:
This project should refresh and cleanup these works-in-progress. The OpenBSD's MPLS stack or the NetBSD's MPLS stack can also be used as inspiration.
Linuxulator on powerpc64
Mentor |
Justin Hibbits <jhibbits AT FreeBSD DOT org>, Brandon Bergren <bdragon AT FreeBSD DOT org> |
Skills |
C (intermediate), kernel (intermediate) |
Duration |
175 hours |
Difficulty |
Medium |
Expected Outcome |
Simple Linux binary support on FreeBSD/powerpc64 |
Description
FreeBSD provides optional binary compatibility with Linux, allowing users to install and run unmodified Linux binaries. The Linux binaries can be started in the same way native FreeBSD binaries can. They behave almost exactly like native processes and can be traced and debugged the usual way. The "linuxulator" is available for the i386, amd64, and arm64 architectures. This aim of this project is to add preliminary linuxulator support for FreeBSD/powerpc64.
Implement Netlink (RFC 3549) kernel support
Mentor |
Alexander Chernikov <melifaro AT FreeBSD DOT org>, Mahdi Mokhtari <mmokhi AT FreeBSD DOT org> |
Skills |
C (intermediate), Kernel (intermediate) |
Mid-term deliverable |
able to setup AF_NETLINK sockets and pass a request to the routing subsystem (NETLINK_ROUTE) |
Duration |
350 Hours |
Difficulty |
Medium |
Expected Outcome |
Routing daemon of choice (bird,frr,..) is able to interact with kernel routing subsystem via netlink. implement another netlink family, preferrably NETLINK_KOBJECT_UEVENT |
Description
Netlink is widely used in Linux for many network-related kernel to userspace communications. Many apps require kernel netlink support to work, making them hard to port to FreeBSD. The goal of this project is to add Netlink support to FreeBSD kernel for route and notification protocol families.
Add support for building Linux-only network drivers
Mentor |
Mahdi Mokhtari <mmokhi AT FreeBSD DOT org> |
Skills |
C (intermediate), Kernel (intermediate), Network |
Mid-term deliverable |
Have netlink base functionalities working |
Duration |
350 hours |
Difficulty |
Hard |
Expected Outcome |
Be able to build a sample Linux-only network driver (Freifunk?) for FreeBSD |
Description
Currently we have a Linux KPI for FreeBSD which mostly helps drm-next graphical stack to work.
The big-picture idea is to have network functionalities implemented in that way, so that we can build "Linux-only" network drivers for FreeBSD too. To accomplish this, he first step is to implement the API (KPI) most Linux drivers rely upon. Netlink is one example.
The steps (the first or at max 2nd one are for current/2022 GSoC)
- Implement netlink
- Implement base functionalities (ioctl behavior)
- Implement Netlink protocols (NETLINK_ROUTE, FIREWALL, etc)
- Build a sample driver using new API
Userland projects
ELFToolChain improvements
Mentor |
Ed Maste <emaste AT FreeBSD DOT org> |
Skills |
C (intermediate) |
Mid-term deliverable |
LLVM bytecode support for ar/nm/ranlib |
Duration |
175 or 350 hours |
Difficulty |
Easy |
Expected Outcome |
Support archive files containing LLVM bitcode |
Description
The elftoolchain project provides FreeBSD with several commands for handling ELF executables, including "ar", "addr2line", "elfdump", "nm", "strings", amongst others. These replaced the equivalent tools from GNU binutils. A useful project needed to support LLVM's Link-Time-Optimization would be to extend ar, ranlib and nm to support archive files containing LLVM bitcode files. These files have their own container format; the project would involve adding a small parser that is sufficient to extract information required by these tools (e.g., the symbol table).
Another potential task within the project would be to investigate the GNU binutils test suites for these tools and attempt to run them using the ELFToolChain equivalents, with the aim of finding and fixing bugs and incompatibilities.
Kernel LLDB debugger module support and integration
Mentor |
Ed Maste <emaste AT FreeBSD DOT org> |
Skills |
C++ (intermediate) |
Mid-term deliverable |
Parse and report the kernel module list in a coredump |
Duration |
175 or 350 hours |
Difficulty |
Easy |
Expected Outcome |
crashinfo functional with LLDB rather than kgdb |
Description
LLDB is the debugger in the LLVM family of projects. It has supported userland debugging on FreeBSD for a long time, but kernel debugging support was added recently under FreeBSD Foundation sponsorship. One outstanding item remaining with kernel debug support is to handle kernel modules - that is, parse the loaded module data provided by the kernel (live or core dump) and loading the kernel module objects. This project will require at least intermediate skill with C++ (the language in which LLDB is written), as well as familiarity with C (the language used by the FreeBSD kernel).
This project may be short or long. Minimum requirement for a short project is support for one type of kernel module ELF object and one supported FreeBSD architecture. A long project would include both kernel module types and multiple FreeBSD architectures, as well as integration with the rest of the system.
UFS4fuse: support FreeBSD's UFS2 with fusefs
Mentor |
? |
Skills |
C (expert), fusefs (expert) |
Mid-term deliverable |
Read-only support for userland |
Duration |
350 hours |
Difficulty |
Hard |
Expected Outcome |
Fully functional UFS with basic read and write support |
Description
FreeBSD's UFS is arguably the longest standing UNIX file system still under active development. It is well documented and has many interesting features. While UFS has been ported to Linux and Mac OSX, the ports are not very good or have been deprecated. Using fusefs as a userland option would let the filesystem be used on many other systems. Existing FreeBSD headers and code can be reused but a fresh design using modern C++ constructs would be interesting.
This project is challenging: any proposal must include a coding plan and should include credible evidence of userland filesystem development.
syzkaller improvements
Mentors |
Andrew Turner <andrew AT FreeBSD DOT org>, Mark Johnston <markj AT FreeBSD DOT org> |
Skills |
golang (intermediate), kernel (intermediate) |
Duration |
350 hours |
Difficulty |
Hard |
Expected Outcome |
Complete FreeBSD syzkaller extenstions described below |
syzkaller is a suite of tools that performs coverage-guided system call fuzzing. Originally targeting Linux, it can now fuzz many different operating system kernels and has been extremely effective at finding bugs, many with security implications. It creates, monitors and fuzzes a set of virtual machines running the target kernel. More information can be found in its documentation, and in these slides. Google kindly runs a public syzkaller instance targeting FreeBSD.
For a while it has been possible to run syzkaller on FreeBSD; that is, fuzz FreeBSD on FreeBSD. syzkaller makes use of ZFS and bhyve (or QEMU) to do so. This makes development and testing of FreeBSD-specific syzkaller features much easier.
Though syzkaller has found quite a few bugs in FreeBSD, it does not cover as much as it does on Linux, so it is virtually guaranteed that there are plenty of bugs waiting to be found. This project consists of several subtasks that would improve FreeBSD's coverage:
- Extend syzkaller's FreeBSD system call descriptions. For each system call, syzkaller requires a set of annotations that describe the system call's arguments. It is missing many of FreeBSD's system calls. syzkaller similarly needs to be taught about device-specific ioctls.
- Support fuzzing of FreeBSD's Linux system call compatibility layer. Since syzkaller can of course fuzz Linux natively, it should be straightforward to run a Linux fuzzer on FreeBSD.
- Support external injection of USB traffic.
- Support running the fuzzer in a jail, optionally with various resource limits in place.
- Test syzkaller with a ZFS root filesystem instead of UFS. Work with the syzkaller developers to get a FreeBSD+ZFS target running in syzbot.
Port support for automated patch testing and crash bisection to FreeBSD. Some details are listed here.
- Work with the project mentor to triage and possibly fix any kernel bugs found in the process.
Note: contributing to syzkaller requires signing the Google CLA. Please make sure that this is acceptable before attempting this project. Note also that working with syzkaller is probably easiest on a dedicated hardware system with a reasonably large amount of disk space (several hundred GB should be sufficient), ideally running FreeBSD on ZFS. syzkaller can instantiate VMs on Google Compute Engine and fuzz them, so this may be an option as well. Please contact the project mentors for details.
Move to GENERIC armv7 distribution scripting
Mentor |
Warner Losh <imp AT FreeBSD DOT org> |
Skills |
Shell / Make (intermediate) |
Mid-term deliverable |
release scripts working, u-boot ports updated |
Duration |
175 hours |
Difficulty |
Medium |
Expected Outcome |
Documented and tested user tool to generate generic image |
Description
FreeBSD has grown support for a large number of boards over the past few years, far too many to release images for all of them. This project would convert the release tools to generate only a generic image that can have any supported u-boot port overlaid. the u-boot ports would need to be updated with meta-data that would describe how each SoCs or board's u-boot and other pieces are placed into an image. A simple user-land script needs to be created to take a u-boot package for board X and the generic bootable distribution and make an image that's bootable on board X. This project could be combined with the mining script project described below to creata a 350-hour project.
Move to GENERIC armv7 distribution web interface
Mentor |
Warner Losh <imp AT FreeBSD DOT org> |
Skills |
Shell / Make (intermediate) |
Mid-term deliverable |
scripts to mine u-boot ports and screen mock-ups |
Duration |
175 hours |
Difficulty |
Medium |
Expected Outcome |
Working Web tool to mine u-boot |
Description
FreeBSD has grown support for a large number of boards over the past few years, far too many to release images for all of them. We need a way to securely distribute boot images for dozens or even hundreds of boards. The web app would collect user input, run a script to generate the image, sign the image with a secure signing key, then download the results to the user. This project could be combined with the release script project described above to creata a 350-hour project.
Capsicumization of the base system
Mentor |
Mariusz Zaborski <oshogbo AT FreeBSD DOT org> |
Co-Mentor |
Mark Johnston <markj AT FreeBSD DOT org> |
Skills |
C (intermediate), familiarity with the UNIX programming environment |
Mid-term deliverable |
Sandbox a few of the target applications |
Duration |
350 hours |
Difficulty |
Medium |
Expected Outcome |
Sandbox the complete list of target applications |
Description
Capsicum is a sandboxing technology used in FreeBSD. It is complemented by Casper, a framework for defining application-specific capabilities. A large number of utilities in the FreeBSD base system have been converted to run under Capsicum and Casper, but many programs have yet to be converted. The project would consist of identifying several high-profile daemons and utilities in the base system or ports, and modifying them to run in capability mode. One good candidate is syslogd, the system logging daemon.
As part of this work it may be necessary or useful to add additional Casper services to the base system. For example, we do not yet have a Casper service which allows an application to make outbound network connections.
Note: Converting applications to run under Capsicum/Casper can take a lot of effort, especially when they are large or when they are not designed with privilege separation in mind. Some applications, like a shell, can't really be run in capability mode at all. Before attempting to sandbox a given application, take care to study the ways in which it interacts with the system. For example, does the application need to open any files? If so, are the file names statically defined or are they derived from user input? This will provide insight into the difficulties that will arise when sandboxing the application.
Network Configuration Libraries
Mentor |
? |
Skills |
C (intermediate), knowledge of networking and NAT |
Mid-term deliverable |
Library to configure IPFW NAT to allow a bhyve VM guest to reach the Internet |
Duration |
350 hours |
Difficulty |
Medium |
Expected Outcome |
A library to manage NAT configuration for VMs and Jails |
Deliverables
A simple tool to configure the network on a laptop to allow a bhyve VM to access the internet.
Use Cases:
- A bhyve VM running on a laptop NAT'd out the laptop's wifi connection
- A bhyve VM bridged to the hosts Ethernet network
Stretch goal: Extend the tool to support configuring network access for standard and VIMAGE jails
Description
Build a libipfw to enable programmatic configuration of the firewall, implement basic functionality to add rules and configure NAT instances.
Optional: relocate most functionality available in the command line interface into the library and replace the replace the command line interface with a thin wrapper around the new library.
Build a libbsdnat that can be used by bhyve VM managers and Jail management tools to configure NAT on the host to allow the guest access to the internet via the host's network. This library will then be extended to handle creating 'port forwarding' rules to expose services in the guest to the public network via the host. Network mappings will be ephemeral and will need to be recreated by the management tools when the VM or jail is restarted.
Possible design for final tool:
- libifconfig - used to create and manage bridge interface for bhyve, epairs for jails
- libbsdnat - Configure NAT for outbound, and port forward rules for inbound.
- libipfw - Used to insert rules routing traffic via above NAT instances.
Audit Base for Read-Only and NFS Mount Compatibility
Mentor |
Emmanuel Vadot manu@FreeBSD.org |
Skills |
/bin/sh (moderate), System and Network configuration, sqlite, berkelydb and similar (moderate), hier(7) and general FreeBSD base awareness |
Mid-term deliverable |
Identification of in-base components that are r/o or NFS incompatible |
Duration |
175 hours |
Difficulty |
Medium |
Expected Outcome |
Report on the nature of each incompatibility, ideally with proposed solutions. Kyua test suite modules for each issue identified |
Description
FreeBSD has supported read-only and "root on NFS" for decades but has not experienced consistent testing for compatibility under these circumstances. Issues can include the failure of utilities to create temporary files and locking failures with "databases" such as /etc/pwd.db, /var/db/pkg/local.sqlite and /var/db/xenstore/dbf. Temporary workarounds include tmpfs(5) mounts for directories such as /var/db/<utility>, MD/MFS mounts, iSCSI/FC/ggate devices, or network-based authentication. Long-term solutions can follow the model of pkg(8)'s NFS_WITH_PROPER_LOCKING=yes option.
Search terms to help understand the problem: "NFS flock", "sqlite on NFS". Motivation: "Cloud" and "Container" environments often achieve statelessness via simple mechanisms like read-only and network file system mounts.
PJDFSTest rewrite
Mentor |
Alan Somers <asomers AT FreeBSD DOT org> |
Skills |
Python (beginner), familiarity with the UNIX file system concepts |
Mid-term deliverable |
Port a few directories worth of tests |
Duration |
500 hours |
Difficulty |
Easy, but long |
Expected Outcome |
Rewrite pjdfstest, create a port, and integrate into CI |
Description
pjdfstest is a file system test suite, and it's probably the most comprehensive file-system-agnostic test suite in existence. Originally written to validate the ZFS port to FreeBSD, it now supports multiple operating systems and file systems. But it has a few problems:
- TAP encourages large monolithic tests instead of small isolated ones. Some of pjdfstests's test have more than 1000 assertions, making it difficult to understand what went wrong in the case of failure.
No parameterization. Many test cases contain loops like for type in regular fifo block char socket symlink ... that run the same test on different file types. But these aren't fully isolated. In this example, the fifo tests depend on whatever happened during the regular tests. Test frameworks like pytest and Googletest are natively parameterizable.
- No inheritance. Inheritance is useful for sharing things like common setup/teardown routines between test cases, but it's difficult to do with sh.
- No debuggability. Writing tests in sh made them easy to read and quick to modify, but paradoxically harder to debug, because there's no sh debugger. This is especially important considering the first point: some of the test cases are huge.
- No skipped tests. Frameworks like pytest or atf will print a nice "skipped" message, showing you that the test was skipped. With prove the test case gets modified to simply not try those assertions. There's no feedback that some tests were skipped.
- Limited configurability. pjdfstest has only limited ability to conditionalize optional features on the file system type. Ideally it would be possible to specify a config file defining which features are expected to be supported. That would help downstream users integrate pjdfstest into their own test suites.
- Slow. pjdfstests runs all test cases sequentially. It also contains many 1-second sleeps, which could be briefer if it had better configurability.
- Cannot be run as an unprivileged user.
No ATF integration. This isn't critical, but it sure would be nice if pjdfstest could display detailed results at https://ci.freebsd.org/job/FreeBSD-main-amd64-test/lastCompletedBuild/testReport/ .
A rewrite in Python, using pytest, could fix all of these problems except the last. I have already written a proof of concept demonstrating the basic organization and key features like configurability and privilege modes. However, there are about 7,000 lines of tests that need to be rewritten. This project would be great for a beginner, because each test case is small and self contained, and no advanced skills are required. Also, even an incomplete port would have value. A partial test suite would still be useful for other projects' CI testing, and another student can easily pick up where this project leaves off. The student could also make a case for using a different language than Python. Go and Rust, for example, have been mooted. But you'll need to find a different mentor if you want to use Go.
Build infrastructure
Integrate MFSBSD into the release building tools
Mentor |
Brad Davis <brd AT freebsd DOT org> |
Skills |
C (beginner), make (intermediate), shell (intermediate) |
Mid-term deliverable |
'make release' will build MFSBSD |
Duration |
175 hours |
Difficulty |
Easy |
Expected Outcome |
Completed integration so all new releases of FreeBSD will include mfsbsd media |
Description
MFSBSD is a version of FreeBSD designed to run from memory. It is often used as a rescue system, or the basis for automated installers.
It is currently maintained by a FreeBSD developer, Martin Matuška
The issue is that only images for the release versions are usually produced, and MFSBSD tends to get out of sync with the tools in base. There is a desire to have MFSBSD images of the weekly snapshots of -current and -stable that are created by the release engineering time. This requires that the process be automated as an additional target in the makefile in src/release. It would be similar to the process used now to generate VM images. Adding flexibility to the MFSBSD build system to control additional features would be a bonus
IPv6 support and cleanup of address family dependency in userland utilities
Mentor
Hiroki Sato <hrs AT FreeBSD DOT org>
Skills
C (intermediate), networking (intermediate)
Duration
175 hours
Expected Outcome
Description
This project could also include a broader survey of other network services in /usr/bin and /usr/sbin to make sure they're all IPv6 clean. This project could be further developed. Some more of this includes: