This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Ftrace and Systemtap
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: systemtap at sourceware dot org
- Date: Thu, 01 Apr 2010 11:20:37 -0400
- Subject: Re: Ftrace and Systemtap
- References: <a0af0ed1f97d2d336a72a0e2eacd1163.squirrel@webmail.aber.ac.uk> <4BB39A4A.3020802@redhat.com> <4BB3A316.1050708@redhat.com> <y0mr5n0godn.fsf@fche.csb>
Frank Ch. Eigler wrote:
>
> Masami Hiramatsu <mhiramat@redhat.com> writes:
>
>>> I always hear complaints which systemtap can't be used for the latest
>>> developing kernel. And yes, that's true.
>>
>> It will happen on a personal development branch. (note that
>> all developments are started on a personal branch :))
>> Not(or rarely) on public linus/linux-next tree.
>>
>> If someone changes some APIs which systemtap depends on,
>> systemtap can't work on his kernel.
>> e.g. just removing EXPORT_SYMBOL_GPL(register_kprobe).
>>
>> This also shows why the out-of-tree driver is so fragile.
>
> In theory, that makes a lot of sense.
>
> But you made it sound like in practice it is problematic ("That is
> true."). Please provide some substantiation of this, for anecdotes
> are all I've heard lately. What versions have not worked / when / for
> how long? Who has removed EXPORT_SYMBOL* something essential to
> systemtap (which by the way kprobes aren't)?
Ah, sorry about confusion. I just said that kernel developer's
complaint is true just from their viewpoint.
> I always hear complaints which systemtap can't be used for the latest
> developing kernel. And yes, that's possible.
And indeed, I haven't had any actual problem. It just be possible
to happen (so, the possibility is true.) And if it happened, I guess,
active kernel developers may not want to fix and re-install systemtap
just for catching up their changes.
Thank you,
--
Masami Hiramatsu
e-mail: mhiramat@redhat.com