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

Frank Ch. Eigler
2008-07-23T16:43:35Z

Arjan van de Ven <arjan@infradead.org> writes:

> [...]
>> It does happen to *generate* kernel modules. The way that such a
>> module must interface with any particular kernel is naturally subject
>> to the whims & desires of the kernel du jour. This is why we have a
>> mass of mechanism to try to automatically speak to each kernel version
>> as appropriate.

> and this is where I strongly disagree. THIS part *has* to be in the
> kernel source, so that we can change it WITH the kernel as we change
> it. [...] But to have any chance at all of systemtap being
> sustainable, this part of the stack has to be together with where
> the changes happen.

OK. It will take us some time to figure out to what extent this would
be feasible. Maybe a topic for Portland.

>> It is desirable to minimize this mass for obvious reasons. When a new
>> upstream kernel comes out with a tasty new feature -- or a less tasty
>> API rewrite -- we need to extend systemtap to support that too.
>
> At that point you are already 3 months too late for me, and probably
> for most of my fellow kernel hackers.

(Really? Have we ever been 3 months behind supporting the git kernel?)

> (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.

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.

- FChE