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

[fche at redhat dot com (Frank Ch. Eigler)]

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