linux-kernel - Re: [PATCH 2/3] perf trace: Update eval_flag() flags array to match interrupt.h

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: <20091011122129.GA16701@infradead.org>
Date:	Sun, 11 Oct 2009 08:21:30 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Tom Zanussi <tzanussi@...il.com>, linux-kernel@...r.kernel.org,
	rostedt@...dmis.org, lizf@...fujitsu.com
Subject: Re: [PATCH 2/3] perf trace: Update eval_flag() flags array to
	match interrupt.h

On Sun, Oct 11, 2009 at 10:53:45AM +0200, Ingo Molnar wrote:
> And you were full of it back then and you are full of it now as well.

Beeing nice today, eh? :)

> Of course tools/perf/ can be dependent on the kernel source, as long as 
> it's all exposed cleanly. Runtime exposure of information is better of 
> course in many cases, but there's a balance to be stricken.
> 
> We already have deep and good dependencies between kernel code and 
> tools/perf: for example we use the kernel's list.h and lib/rbtree.c in 
> perf and those facilities are God-sent over user-space crap that for 
> example Glist is.

Re-using code is no problem at all.  If you look at typical lowlevel
userspace code written by kernel developers you'll notice that they
usually use the kernel data structures, too.  And yeah, glib is
quite horrible.

The problem is run-time depdency on the kernel it was built with.  It's
not practival or desirable to have one perf binary per kernel version.

> I tend to agree that softirq names might make sense to expose runtime as 
> well, but that is totally independent of your _idiotic_ argument that 
> this issue somehow talks against perf being part of the kernel source.

It is directly related.  If you ship perf as part of the kernel source
these kinds of thing slip in easily, just because people don't think
about it enough.  If you have a separate source tree it's much more
clear that you can't depend on internal implementation details.

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