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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080723150434.GC11191@redhat.com>
Date:	Wed, 23 Jul 2008 11:04:34 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	systemtap@...rceware.org
Subject: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

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.

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.

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.  We
cannot easily take old support away, because then the same user-space
code base would no longer run against actually installed kernels.

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.

Things are good however if the low-level userspace changes are
backward-compatible, so that the new kernel facility is used when
present, but the software does not regress if it is not.  I believe
this is what we need to aim for, even though it puts the bulk of the
burden on systemtap (or glibc, or ...).

I hope this fills in some of the gaps in the background.

- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/