From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751993AbbJYQXl (ORCPT ); Sun, 25 Oct 2015 12:23:41 -0400 Received: from mail-pa0-f53.google.com ([209.85.220.53]:36653 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751579AbbJYQXj (ORCPT ); Sun, 25 Oct 2015 12:23:39 -0400 Subject: Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper To: Ingo Molnar References: <1445559014-4667-1-git-send-email-ast@kernel.org> <20151023120335.GZ17308@twins.programming.kicks-ass.net> <562A474E.6040401@plumgrid.com> <20151025092142.GB4380@gmail.com> Cc: Peter Zijlstra , "David S. Miller" , Wang Nan , He Kuang , Kaixu Xia , Daniel Borkmann , netdev@vger.kernel.org, linux-kernel@vger.kernel.org From: Alexei Starovoitov Message-ID: <562D0208.7090608@plumgrid.com> Date: Sun, 25 Oct 2015 09:23:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151025092142.GB4380@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.