Doing things in the kernel [LWN.net]

Kernel developers often put a great deal of effort into keeping tasks out of the kernel; the thinking is that if a task can be done in user space, there's where it should happen. Keeping things out of the kernel helps to keep the kernel code smaller, and it makes it easier for users to set their own policies. Sometimes, however, there are reasons to move tasks which have been performed in user space for a long time over the line and into the kernel. A couple of patches have been circulating recently which do exactly that.

Ingo Molnar's kksymoops patch performs the same task as the classic "ksymoops" utility: it takes the numeric "oops" output from a kernel panic and attaches symbolic information so it actually makes sense to humans. Or, at least to kernel hackers, who really are human, despite occasional rumors to the contrary.

Why move this task into the kernel? Anybody who has actually used ksymoops to get a symbolic trace knows that it can be quite a pain to set up, especially when loadable modules are involved. Without quite a bit of information on the run-time configuration of the actual kernel that was running when the oops happened, ksymoops can not do its job. Expecting casual users (or customers) to set up ksymoops and use it properly when reporting problems is asking too much.

But the kernel itself knows a lot about its current configuration. It's actually not all that hard for the kernel to generate symbolic names for its own addresses; it's just a matter of keeping a symbol table around. If the kernel can generate useful oops reports from the beginning, the kernel developers will get better information on crashes, and problems will get fixed more quickly. It's probably worth the trouble.

Then, there is Rusty Russell's loadable module rewrite. The insmod utility has traditionally done much of the work of loading modules, including tasks like parsing the executable file and doing symbol binding and relocation. Rusty's patch, instead, moves these tasks into the kernel. Thus, with this patch, the kernel is in the business of picking apart ELF binaries and linking symbols itself.

Surely this sort of work belongs in user space, right? Rusty's answer is:

The amount of kernel code required by the new module loader is smaller than the older, "simpler" one. That is because the in-kernel loader has fewer "communication with user space" issues, and doesn't have to deal with differences between the user and kernel space runtime environments.
The amount of user-space code is, of course, much smaller. This reduction is useful for some situations, such as initramfs, where the module utilities need to fit into a small space.
In-kernel module linking is more flexible and has an easier time with tasks like discarding initialization code.
In the end, the whole body of code is simpler.

Whether Rusty will succeed in convincing the other kernel developers remains to be seen. One way or another, he has made it clear that the proper place to draw the line between kernel and user space is not always obvious.

(Log in to post comments)