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
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
- 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
to post comments)