Cherry (cherry@) suggested that it would be interesting if we can use rump
to test the umv_physseg implementation. But before I could do any useful
coding, I first needed to understand what exactly is Rump and how it is useful
in our scenario.
Here is a short definition of Rump and what it does (from the rump kernel FAQ)
A rump kernel is a composition of componentized drivers. More specifically, a rump kernel employs a mechanism for taking an existing monolithic operating system kernel, leaving out everything except drivers, and using those drivers as library components. For example, depending of the set of components you pick, a rump kernel can provide you with PCI drivers, SCSI drivers, a TCP/IP driver, a POSIX system call driver or file system drivers. A rump kernel is agnostic to for example virtual memory and always runs on top of an external scheduler. Leaving the extra policy out makes a rump kernel lightweight and straightforward to integrate into any environment.
That being said, Rump is quite effective in what I would call Isolated Integration Testing of various components from a Kernel perspective. Providing an isolated Kernel runtime space, where the various features of a driver you are testing can be run without interfere with your current host operating system. But there was a catch, Rump does not implement all the necessary details of Virtual Memory so that one could test changes in uvm. Rump eventually relies on the host operating system to do all the necessary dirty work, to quote from the Rumpkernel-book (section 2.4)
Virtual memory address space management in a rump kernel (if any!) is relegated to the host, because requiring support in a rump kernel would impose restrictions on the platform and host.
This did provide a certain challenge on how do you test out uvm_physseg
changes in an isolated environment. In particular our interest lies in executing
uvm_page_physload() to be executing in the isolated Rump environment.