Linux Plumbers Conference 2008

Where should the Line be drawn between kernel and user space? - James Bottomley

Biography

James Bottomley is currently CTO of Hansen Partnership, Inc., a Director of the Linux Foundation and Chair of its Technical Advisory Board. He is Linux Kernel maintainer of the SCSI subsystem, the Linux Voyager port and the 53c700 driver. He has also made contributions to PA-RISC Linux development in the area of DMA/device model abstraction. He was born and grew up in the United Kingdom. He went to university at Cambridge in 1985 for both his undergraduate and doctoral degrees. He joined AT&T Bell labs in 1995 to work on Distributed Lock Manager technology for clustering. In 1997 he moved to the LifeKeeper HA project. In 2000 he Joined SteelEye Technology, Inc as Software Architect and later as Vice President and CTO.

Abstract

What should be in the kernel and what should be in user space has been a subject of fairly perennial debate. The current line has settled on the "policy" question: If it's policy based, it should be done from user space (the kernel is there to implement policy but not to make it). One of the interesting aspects of this edict is the question of when should the actual policy implementation be in user space and when should it be in the kernel. In the latter case, the kernel grows effectively a way of having policy set plus a way of implementing it, usually causing a significant size increase over a simple compile configured static policy. An obvious example of this is ip_tables; it occupies a massive amount of kernel code, all for the purpose of enforcing user defined policy on incoming and outgoing network packets. The complexity of the policy (you try configuring ip_tables in all its glory) necessitates the huge size of the code base to do this. Unfortunately, IP packet routing policy can't simply be ejected to user space if one expects the IP stack to function at speed on a modern network, so we're apparently stuck with it. However, there are numerous other examples, like SCSI scanning that occur inside the kernel but could be done from user space instead.

When you begin thinking about evicting pieces of the kernel out to user space, you immediately run into a functionality and delivery problem: Usually the kernel won't work without the relevant component, plus if it's too tightly bound to the exact operation of the kernel, then the component so ejected has to keep pace with what's going on with the kernel interfaces while being maintained separately (a recipe for disaster). Finally, the more critical user space pieces you have, the harder it becomes for distributions to maintain a working boot sequence correctly (because there are more pieces for them to keep at the right versions in the correct places). On the other hand, certain operations can be performed much more easily in user space because of access to the filesystem and full library interfaces.

This talk will argue for drawing the line closer to the "because we can" pole than we do now by examining a three point test for whether something should be in user space:

It must not be performance critical
The code must be simpler to write in user space
The Kernel/User interface for the component must either be stable or be susceptible to backwards compatibility requirements.

We will case study this approach by examining what happens when the whole of the SCSI subsystem scanning code is moved outside of the kernel.