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. 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". This current issue with the locking doesn't really matter much because as far as I can tell it's an obscure potential corner case that no one has seen in practice yet. So the easiest solution might just be to ignore the whole issue, which is a lot easier than trying to write a custom portable cross-platform license-agnostic memory barrier library. We do try to keep the papi mmap reading code as close to perf's as possible though just because we know you aren't going to notice or care if you break it for other users. Vince -- 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/
