linux-kernel - Re: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk executable

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130813104821.GB2170@gmail.com>
Date:	Tue, 13 Aug 2013 12:48:21 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Vince Weaver <vince@...ter.net>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	acme@...radead.org, Andi Kleen <ak@...ux.intel.com>,
	Namhyung Kim <namhyung.kim@....com>, peterz@...radead.org
Subject: Re: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk
 executable

* Vince Weaver <vince@...ter.net> wrote:

> On Mon, 12 Aug 2013, Ingo Molnar wrote:
> 
> > perf is the exact opposite: no split-up the development culture 
> > because they are closely related, yet a relatively disciplined ABI 
> > between the components. In fact the ABI is higher quality exactly 
> > because development is more integrated and allows for ABI problems to 
> > be resolved before they leak out. It also allows for faster iteration 
> > of development, without nonsensical ABI steps pulluting the way.
> 
> I don't know if I'd use "quality" and "perf ABI" in the same sentence. 
> It's a horrible ABI; it has the honor of having the longest syscall 
> manpage, beating out even ptrace.

The functionality it provides is useful, and comprehensive documentation 
of it is useful as well.

> It also really isn't that stable; I've had perf ABI changes break 
> programs I maintain at least three times in the last 2 kernel releases.  
> Part of this is due to the tight coupling into the kernel, in fact the 
> only ABI anyone seems to care about is that presented by the perf-tool 
> CLI interface; the _actual_ kernel ABI seems like an afterthought.

It's certainly complex, but the main root cause for your problems is what 
I pointed out to you in previous, similar discussions: I'm not aware of 
*any* tester using your library on devel kernels, so regressions in seldom 
used functionality that you rely on simply doesn't get reported.

In the past you used to only test your library once the -stable kernel was 
released - has this changed recently by any chance? I remember that in one 
particular case I got a regression bugreport from you essentially on the 
day of a -stable release.

If you tested -rc2 or so that would give us a much larger window to fix 
any breakages that affect your library. (I'm not even asking for 
linux-next testing.)

tools/perf is used much more prominently and breakages do get reported 
reasonably early, typically before the merge window even opens.

Once we receive a report we do fix your regressions as well and mark them 
for -stable.

To resolve this situation you could help us out by doing either of these:

 1) integrate your tests into tools/, there's 'perf test' that has a ton
    of testcases already

 2) run your testsuite more frequently - instead of waiting for a stable
    kernel to be released and then complain about breakage.

So far you refused to do any of this and blamed others for non-reported 
breakages :-/

Thanks,

	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/