This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] Proposal of marker implementation
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>
- Date: Fri, 01 Sep 2006 11:55:37 +0900
- Subject: Re: [RFC] Proposal of marker implementation
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <44D97397.2080005@hitachi.com> <y0mmz9kdc90.fsf@ton.toronto.redhat.com>
Hi Frank,
I discussed this idea and your question in Hitachi, and I
decide to shelve it, because realizing this idea is not easy
on the other arch, and there are no proofs of big advantages.
I just minded the overhead of current approach which came from
accessing variables. And now I'd like to prioritize other things
which should be done, for example, flight-recorder,
kprobe-booster@other arch, integrated tracing scripts,
and non-marker-based djprobe.
Thanks,
Frank Ch. Eigler wrote:
> Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> writes:
>
>> I'd like to suggest my marker idea which I spoke in OLS.
>> My idea is based on the "section" of elf binary and the djprobe.
>> [...]
>
> Can this approach could be made "pluggable" in the sense of
> interchangeable with the other type at the call site? Can you make a
> version of these macros that adds reliable parameter passing? Can you
> outline a proof-of-concept of the probe that would use these hooks?
> Is live activation/deactivation of the probes a problem on complex
> hosts (smp / preempt)?
>
> - FChE
>
>
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com