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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 13 Aug 2013 10:03:52 -0400 (EDT)
From:	Vince Weaver <vince@...ter.net>
To:	Ingo Molnar <mingo@...nel.org>
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,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk
 executable

On Tue, 13 Aug 2013, Ingo Molnar wrote:
> * Vince Weaver <vince@...ter.net> wrote:

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

I wasn't aware that the Linux "no-ABI breakage guarantee" only applied to 
people who ran -rc kernels.

I've spent a lot of time enhancing trinity and writing my own perf syscall 
fuzzer just to try to keep on top of ABI breaks as per your rules and they 
still slip in and they still don't get reverted.

In any case, a list of perf-related ABI breakages is here.
 http://web.eece.maine.edu/~vweaver/projects/perf_events/abi_breakage.html
I guess whether it's a lot or just a few depends on your perspective.

> 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

I have enough trouble keeping my code up to date let alone wasting weeks 
of time re-sending patches.  Some things are just simpler to maintain 
outside the kernel.

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

I only have so many machines and so much time, and no one is funding me 
for this work.  I run -rc kernels when I can, but perf can be very 
architecture and even CPU dependent so it is hard to get full coverage.  
For example it's hard to test full SNB-EP uncore support w/o such a 
machine.

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