Re: [tip:perf/core] tools/perf: Add required memory barriers

[Ingo Molnar]

* Vince Weaver <vince@xxxxxxxxxx> wrote:

> On Thu, 7 Nov 2013, Ingo Molnar wrote:
> 
> > I don't want a library that is external and under-tested: for example 
> > quite a few of the PAPI breakages were found very late, after a new 
> > kernel has been released - that's the big disadvantage of 
> > librarization and decentralization. The decentralized library model 
> > might work if all you want to create is a second-class also-ran GUI, 
> > but it just doesn't work very well for actively developed kernel code.
> 
> I would argue that PAPI's problem was because it was trying to use 
> perf_event_open() which is a complex, poorly documented kernel interface 
> with a lot of code churn.  Usually it's the job of the kernel not to 
> break user-space, not the other way around.

As Linus said it on the Kernel Summit: breakages that don't get reported 
or don't get noticed essentially don't exist. We can only fix what gets 
reported in time.

> It's too late on the decentralized library issue.  PAPI has to support 
> kernels going back to 2.6.32 so it's going to have its own copy of the 
> mmap parsing code even if a new syscall gets introduced.
> 
> There are a lot of tools out there now that open-code a perf_event 
> interface.  I don't think it's really possible to say "anyone using the 
> syscall without using our kernel library is unsupported".

I'm not saying that at all - but you appear to expect perfect kernel code 
and fixes done before you report them: that's an impossible expectation.

It's your choice to live outside the space that we readily test and it's 
your choice to not test your bits with a new kernel in time. Others do not 
test your code with -rc kernels, they don't report the bugs, so some bugs 
that affect the PAPI library go unnoticed. Yet you try to blame it on us, 
which is really backwards ...

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/