Re: 02-16-2006 meeting minutes

[fche at redhat dot com (Frank Ch. Eigler)]

> [...]
> Frank wanted kprobes to have three states - 
> 	1) no kprobe.
> 	2) kprobes registered, but not running
> 	3) kprobes is running.

More precisely, I meant that if the various hooks kprobes has in the
kernel could differentiate between these three cases, more
optimization opportunities may show up.  For example, it would be
desirable to avoid any kprobes-related overhead for a system in state 1.

> [...]
> Frank suggested that kprobes fault handler should do more of the general
> cases too instead of just pagefault case as it does now.
> [...]

To clarify, I suggested that the kprobes fault handling logic should
eventually make it possible to catch all of these occurring in a
pre-handler:
- The current user- and kernel-side pointer dereference macros that
  contain exception fixup tables.
- Other page faults that may originate from systemtap code *without* 
  fixup tables, such as embedded-C.
- Faults other than page faults.
Ideally, all these should be able to do a setjmp/longjmp inspired
return into the pre-handler, where systemtap-generated code can
signal an error and clean up.


- FChE