linux-kernel - Re: 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-next>] [day] [month] [year] [list]

Date:	Wed, 23 Jul 2008 12:41:37 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Rik van Riel <riel@...hat.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	systemtap@...rceware.org
Subject: Re: systemtap & backward compatibility, was Re: [RFC] systemtap:  begin the process of using proper kernel APIs

Arjan van de Ven <arjan@...radead.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
--
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/