Re: can kprobes be modular?

[richardm <rasman at uk dot ibm dot com>]

Well, in  a sense this has already been investigated. kprobes was what 
was left when we reorganized dprobes in to a kernel module with a 
minimal pair of kernel APIs. 

In the early days of working on RAS for Linux I was under the impression 
that this type of functionality would be more acceptable to the kernel 
community if it were made optional as an installable module. It turned 
out that I was wrong in that assumption. I was told frequently by a 
number of key figures that what mattered was whether this functionality 
was relevant, needed and correctly designed. Placing an artificially 
boundary round some of the code did not affect those considerations. So, 
kprobes emerged from dprobes. It was further refined and simplified. 
Linus pronounced it to be 'cool' and the deal was done.

If we re-examine this proposal we have to understand clearly what is to 
be gained. If we can remove all knowledge of kprobes from the kernel 
then there's a possible case. But I am certain there are not sufficient 
interfaces to allow that to happen, in which case we end up with a 
hybrid situation and possible more interfaces to support the extraction 
of some of the code. Also, if we removed kprobes to a module, how 
independent of the kernel will that module be? If it's intimately 
dependent on kernel internals then I see no point in creating the 
illusion that it is independent.  

Having kprobes in a loadable module would make any chance of using 
kprobes early in system initialization almost impossible.

This comes down to a broader question of whether the kernel should be 
modularized. The case for this seems to be mainly ease kernel 
maintenance in a binary maintained environment. 

R.

--
Richard J Moore
Tel: (44) 1962-817072
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU