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
here)
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.