[lkml]   [2013]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk executable

* Vince Weaver <> 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 :-/



 \ /
  Last update: 2013-08-13 13:21    [W:0.096 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site