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]

Date:	Sun, 11 Oct 2009 10:53:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	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

* Christoph Hellwig <hch@...radead.org> wrote:

> On Tue, Oct 06, 2009 at 05:19:00PM +0200, Frederic Weisbecker wrote:
> > Yeah. We may want to do that by including trace/events/irq.h
> > and then use the show_softirq_name() macro defined there.
> > 
> > The rest of the header can be wrapped through no-op macros and
> > stub includes.
> 
> No, not at all.  Performance tracing tools really should not be 
> dependent on the kernel source.  This kind of creep is exactly what I 
> feared from putting the perf source in the kernel tree.

And you were full of it back then and you are full of it now as well.

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.

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.

Really, give up that argument already - or if not, please engage in an 
open, honest exchange about it. These drip-drip attacks you are doing, 
without actually having the balls to argue your technical position are 
somewhat annoying.

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