This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Karim Yaghmour <karim at opersys dot com>
- To: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- Cc: Richard J Moore <richardj_moore at uk dot ibm dot com>, Mathieu Desnoyers <compudj at krystal dot dyndns dot org>, Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Masami Hiramatsu <masami dot hiramatsu at gmail dot com>, michel dot dagenais at polymtl dot ca, Roland McGrath <roland at redhat dot com>, Satoshi Oshima <soshima at redhat dot com>, sugita at sdl dot hitachi dot co dot jp, systemtap at sources dot redhat dot com
- Date: Thu, 28 Jul 2005 21:41:52 -0400
- Subject: Re: Hitachi djprobe mechanism
- Organization: Opersys inc.
- References: <44BDAFB888F59F408FAE3CC35AB4704101E98465@orsmsx409>
- Reply-to: karim at opersys dot com
Keshavamurthy, Anil S wrote:
> Yup, I agree with you and this seems to the correct way to support
> djprobe
> with having to worry about all the other issues which we have discussed
> earlier.
> The only _limitations_ here is that djprobe can only be placed if there
> is a static hook as mentioned above.
Actually given that kernel hooks has been around for a very long time, and
since static probe points are required anyway, I'm thinking of actually
reusing as much from kernel hooks as possible to implement the dynamic
instrumentation component of the kernel markers.
Now if only I could find the pages where IBM now hosts its projects ...
there are a lot of broken pointers when trying to access stuff like
kernel hooks, dprobes, kprobes, etc. Google, at least, can't find
anything meaningfull.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546