* 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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|