linux-kernel - Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol

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]

Date:	Tue, 22 Jul 2008 20:31:17 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
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: [RFC] systemtap: begin the process of using proper kernel APIs
	(part1: use kprobe symbol_name/offset instead of address)

On Tue, 2008-07-22 at 14:11 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Tue, Jul 22, 2008 at 02:00:15PM -0400, Rik van Riel wrote:
> > [...]
> > > Yes, that is generally desirable - each case is usually a question of
> > > cost/benefit.  One significant requirement for us is to keep working
> > > with older kernels.
> > 
> > You will have to weigh that against the benefits of making
> > systemtap generally useful for kernel developers [...]
> 
> Understood & agreed, Rik.  If an issue arises where there is genuine
> conflict between kernel-developer-usability and something else, we'll
> try to solve it favouring the former if at all possible.
> 
> (The kprobes addressing argument cannot reasonably be placed into this
> category.)

You have your viewpoint inverted, if the kernel developers think you
have a problem, and you fail to address it, they will walk away.

If you want the kernel people to endorse your project, you'll have to
please them. Its that simple. If that means having to radically
re-structure your design, and/or break backwards compatibility then so
be it. Such are the costs for not collaborating from the start.

If you stubbornly refuse to co-operate you'll either break the project
or invite a fork/rewrite by someone else if the idea is deemed
worthwhile enough.

--
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/