On 10/25/15 2:21 AM, Ingo Molnar wrote:
Then old crap can be de-emphasised and eventually removed, instead of having to live with crap forever ...
strongly disagree. none of the helpers are 'crap'. bpf_perf_event_read() muxes of -EINVAL into return value, but it's non ambiguous to the program whether it got an error or real counter value. So it's not pretty, but it's a reasonable trade off. Properly written bpf programs will not be hitting the error path (which is there for safety and protection against buggy programs) and will consume return value without any extra checks. bpf_perf_event_read() could have been done via passing a pointer to stack where counter value can be stored, but that is much slower, since program would need to init the stack and pass pointers while helpers are not inlined, so the cost of return via stack is higher than returning by value. In this case bpf_perf_event_read() can be hot, so makes sense to optimize and sacrifice 'pretty' factor. All existing helpers have use cases behind them and none overlap, so not a single one can be 'deprecated'. In general I don't think it's worth to make an exception in the kernel that some interfaces are not ABI. That will give a bad impression on the kernel overall. Either we have generic deprecation mechanism for everything or none and my vote is for none. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
