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

[Arjan van de Ven <arjan@infradead.org>]

On Wed, 23 Jul 2008 11:04:34 -0400
"Frank Ch. Eigler" <fche@redhat.com> wrote:

> Hi -
> 
> I wrote:
> 
> > > [...] One significant requirement for us is to keep working with
> > > older kernels.  [...]
> 
> Maybe it's worth elaborating on why the need for backward
> compatibility is different for systemtap than for typical kernel-side
> code.
> 
> The bulk of systemtap is a user-space program, and it does very
> user-spacey things like parsing dwarf and invoking compilers, running
> network servers.  Soon it will include user-space libraries.  It is so
> different from the stuff normally found there that no one has AFAIK
> seriously proposed that the entire software be made part of the kernel
> git tree.  So it is an ordinary separate user-space package, built by
> users and distributors.

so far so good...

> 
> 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. If this means that there's some
userland .so code in the kernel source, so be it. If it means we provide
some template files that your userland fills in the blanks for, even
better. (paint-by-number kernel modules!)

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.

> 
> 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. THIS is exactly what makes
systemtap not usable for kernel hackers, and this is exactly why you
see very little contributions from kernel hackers.
(and when it's seen it gets a rather luke warm reception, but that's a
different story).

It also means that unless I want to package and build systemtap myself,
I have to wait for my OS vendor to think about moving to the kernel I'm
on before I can use systemtap. For me as kernel developer.. that's the
second show stopper already.


> To draw an analogy, systemtap is somewhat like low-level userspace
> code like glibc or syslogd or udevd.  I hope no one would seriously
> propose casually committing code to those packages that would make
> them unusable on prior kernel versions.  Accepting such a patch would
> require their maintainers to fork outright every time a kernel change
> occurs.

we've discussed pulling udev into the kernel source several times, and
the jury is still out on it.
But systemtap is NOT like udev or glibc or ..
it's a kernel component.. at least the part that generates the kernel
code is. it needs to breathe and move together with the kernel.
> 
> I hope this fills in some of the gaps in the background.

it explains where you're coming from, which is good. However I for one
really disagree with the assumption, and i just tried to point out that
the consequences of this are rather dreadful.

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org