Well, that's how all the NetBSD rump drivers work. IIUC, a while back they refactored all the drivers to interact with the NetBSD kernel through the Rump inter

Well, that's how all the NetBSD rump drivers work. IIUC, a while back they refactored all the drivers to interact with the NetBSD kernel through the Rump interface. Which means that all the drivers can work in a traditional monolithic kernel, or can be extracted and used piecemeal in your own kernel, or compiled directly into the application as a unikernel. Checkout http://rumpkernel.org/ http://rumpkernel.org/ for more info. I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent. Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick). But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)