Skip to contentSkip to conversation

Kernel Probes - Is this the same as dynamic probes?

DISCUSSION Mike Grundy 3 participants 3 messages Oct 22, 2002

lore
Share & tools
lore
#0 lore raw

Hi Folks -

Rob posed the question in his merge candidate list. Kprobes is an api for placing arbitrary break (probes) points in kernel code and provides for handlers (your function) to execute before and after the probed instruction is executed.

Dynamic probes on the other hand does the same thing ;-)

Vamsi and co. designed kprobes to provide the core of the dprobes
engine: probe point management and insertion, probe point interrupt handler, and post interrupt clean up (replacing the original instruction, single stepping it and then putting the probe back) in a lightweight patch so that it would be more palitable for inclusion in the kernel.

The next version of dprobes could use the api as well as any module thrown together to debug a problem (without having to reboot).

Anyway getting back to my quip about dprobes doing the same thing, dprobes can put probes in kernel or userland code, has a debug engine we call the dprobes_interpreter that runs probe point handler programs (kind of pseudo assembler programs) that can change / record register values, change / record memory locations, core the process or call LKCD and much more.

kprobes doesn't have two things (IIRC) it needs to handle userland probe points, I don't know if this was a planned addition or if Vamsi figured out a way to handle it within the existing kprobes api.

dprobes has support for i386, s390, s390x, ppc and ppc64. kprobes has i386 support right now, and after we review and beat upon the code I posted to the dprobes list tonight, we'll have s390 and s390x support as well.

Comments welcome.

Thanks
Mike

--
If we blow up, whatever's left of me is kicking your butt!

#1 lore raw
Quoted 26 lines · Mike Grundy

Hi Folks -

Rob posed the question in his merge candidate list. Kprobes is an api for placing arbitrary break (probes) points in kernel code and provides for handlers (your function) to execute before and after the probed instruction is executed.

Dynamic probes on the other hand does the same thing ;-)

Vamsi and co. designed kprobes to provide the core of the dprobes
engine: probe point management and insertion, probe point interrupt handler, and post interrupt clean up (replacing the original instruction, single stepping it and then putting the probe back) in a lightweight patch so that it would be more palitable for inclusion in the kernel.

The next version of dprobes could use the api as well as any module thrown together to debug a problem (without having to reboot).

Anyway getting back to my quip about dprobes doing the same thing, dprobes can put probes in kernel or userland code, has a debug engine we call the dprobes_interpreter that runs probe point handler programs (kind of pseudo assembler programs) that can change / record register values, change / record memory locations, core the process or call LKCD and much more.

Quoted 3 lines

kprobes doesn't have two things (IIRC) it needs to handle userland probe points, I don't know if this was a planned addition or if Vamsi figured out a way to handle it within the existing kprobes api.

Yes there's a patch to add user space probes enablement to kprobes which Vamsi should be posting shortly along with patches for watchpoint support using debug registers (he'll be back in office later today).

Quoted 17 lines

dprobes has support for i386, s390, s390x, ppc and ppc64. kprobes has i386 support right now, and after we review and beat upon the code I posted to the dprobes list tonight, we'll have s390 and s390x support as well.

Comments welcome.

Thanks
Mike

--
If we blow up, whatever's left of me is kicking your butt! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
http://www.tux.org/lkml/