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] [day] [month] [year] [list]

Date:	Fri, 16 Oct 2009 10:47: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 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? :)

Yeah, being reciprocal to you ;-)

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

But we release a new version of perf per kernel release. So we have a 
perf binary per kernel release _already_.

Yes, it's good to avoid coupling but it's not nearly as much of a 
problem as you make it out to be. You seem to argue in favor of some 
sort of inflexible, rigid cage for instrumentation apps and that's 
simply the wrong mindset. That kind of rigidity and isolation kept Linux 
instrumentation poor for a decade to begin with.

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

Exactly where is the problem? You say things like 'bad' and 'mess', 
without actually articulating a single practical disadvantage.

Sure if you go back to an old kernel with new instrumentation binary you 
might get the wrong softirq names. It doesnt really matter in practice: 
'perf' can be built in any past kernel and can be used there.

Fact is, using information from the kernel source has its clear 
advantages. There's lots of details we dont want to guarantee in the ABI 
sense yet. Amongst them are the softirq names. They get changed all the 
time and softirqs might even go away entirely. It's good for tools to 
have _some_ notion about them - but to guarantee it until eternity? No 
way is that an unconditionally good thing.

	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/