- Contact: tech-kern
- Mentors: Christoph Badura
- Duration estimate: 350h
Description
NetBSD has an extensive test suite that tests native kernel and userland code.
Mounting the root file system is one of the last steps the kernel does during boot before starting the first process (init(8)).
Root file system selection is not covered by the current test suite.
How to find the root file system is specfied in the kernel configuration file. E.g.:
config netbsd root on ? type ?
config netbsd root on sd0a type ?
The first is a wildcard specification which causes the kernel to look for the root file system on the device that the kernel was booted from. The second form specifies the device and partition that contains the root file system. Other forms are also possible.
The selection process is a complex interaction between various global variables that get initialized from the kernel configuration file and by machine specific code that processes the information passed by the bootloader about where the kernel was loaded from.
This selection process is performed mostly by a function named setroot
in the file sys/kern/kern_subr.c.
The project could be completed in a number of steps:
- Document the existing use cases and
config ...syntax. - Document the processing steps and functions called by
setroot. - Document how the various global variables interact.
- Write unit tests using rumpservers for the ATF framework for the documented use cases.
The project would initially be focussed on x86 (amd64 and i386).
To a certain extent this is a research project. The existing rump-based kernel tests use rump components and factions that are encapsulte kernel functionality with clear boundaries. This project deals with code in the kernel that can't easily be separated into an independent module.
Project Status
This project was worked on Diviyam Pathak for Google Summer of Code 2024. We ran into bugs in other areas, particularly in using vnd(4) in a rumpkernel that we couldn't resolve in time for the project to make use of it. Therefore Diviyam had to resort to stubbing and mocking of functions. Diviyam's work can be found in his Github repository documenting his project.