Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

[Masami Hiramatsu <mhiramat@redhat.com>]

Hi Frank,

Frank Ch. Eigler wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
[...]
>> (and when it's seen it gets a rather luke warm reception, but that's
>> a different story).
> 
> I hope the backward compatibility issue, as it stands today, helps
> explain the reasons for the current deal with kprobes.

I understood that the current deal with kprobes is also for integrating
user probe logic and kernel probe logic.
Obviously, it is hard uprobe to provide same symbol_name interface,
because it requires to access(and analyze) userspace symbol
information from kernel.

> In the interim (before we come up with a way of moving more
> kernel-coupled systemtap code into kernel.org/git), would y'all
> consider an arrangement?  Those of you who care about systemtap, and
> are intending to make an incompatible kernel/module interface change,
> please run the systemtap testsuite before & after.  If it regresses,
> send us a note or a patch.  If practical, we'll integrate it (and add
> any backward-compatibility hacks if needed) into systemtap.

Hmm, I think it's very costly way for both of kernel developers and
systemtap developers.
From the long term of viewpoint, I think it's better (less costly)
to merge systemtap runtime/tapset into upstream kernel and maintain
it. Then, we can stabilize its API by ourselves on upstream.
Since it reduces the catchup/maintenance cost and it enables users
to use stap on upstream kernel, I think it is benefit for both.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com