[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1308130955360.4537@pianoman.cluster.toy>
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/
Powered by blists - more mailing lists