Messages in this thread | | | Date | Wed, 23 Jul 2008 18:12:37 -0400 | From | Masami Hiramatsu <> | Subject | Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs |
| |
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
| |