Re: can kprobes be modular?

[Roland McGrath <roland at redhat dot com>]

> What do we gain by making kprobes a module?  

A few pages of memory on the millions of systems running at any given
moment that have never installed a kprobe.  Really it's just a principle
of cleanliness thing.  As recent posts have reminded us, some people feel
more secure by not having kprobes available; I don't think that is a very
rational position, since it boils down to wanting control over what
modules might be loaded into your kernel, and the need for that control
exists independent of kprobes or any other particular in-kernel API.

As I said, I'm not especially lodging any demand for this.  It just came
up in thinking about the state of clean isolation of components in the code.
I'd like to get a consensus on the set of issues that would arise.

> On the s390 side, kprobes is dependent code in the core exception 
> handlers in entry.S.  

I don't see any CONFIG_KPROBES code in there.  On all platforms it's
dependent on the hardware traps leading to a notify_die call.  That is
already modular in a pretty minimalist sort of way.  If there is
something in particular that would need to be exported on s390 for
kprobes to be in a module, please elaborate.


Thanks,
Roland