* Vince Weaver <vi...@deater.net> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
