1lfCtJ9

81The Benefit of a printf-like HypercallThe rumpuser_dprintf() call has the same calling convention as the NetBSD kernelprintf() routine. It is used to write debug output onto the console, or elsewhereif the implementation so chooses. While the kernel printf() routine can be usedto produce debug output via rumpuser_putchar(), the kernel printf routine inkernellocks to synchronize with other in-kernel consumers of the same interface.These locking operations may cause the rump kernel virtual CPU context to berelinquished, which in turn may cause inaccuracies in debug prints especially whenhunting racy bugs. Since the hypercall runs outside of the kernel, and will not unschedulethe current rump kernel virtual CPU, we found that debugging informationproduced by it is much more accurate. Additionally, a hypercall can be executedwithout a rump kernel context. This property was invaluable when working on thelow levels of the rump kernel itself, such as thread management and CPU scheduling.3.3 Rump Kernel Entry and ExitAs we discussed in Chapter 2, a client must possess an execution context before itcan successfully operate in a rump kernel. These resources consist of a rump kernelprocess/thread context and a virtual CPU context. The act of ensuring that theseresources have been created and selected is presented as pseudocode in Figure 3.4and available as real code in sys/rump/librump/rumpkern/scheduler.c. We willdiscuss obtaining the thread context first.Recall from Section 2.3 that there are two types of thread contexts: an implicit onewhich is dynamically created when a rump kernel is entered and a bound one whichthe client thread has statically set. We assume that all clients which are criticalabout their performance use bound threads.