From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752131AbbEAQ4a (ORCPT ); Fri, 1 May 2015 12:56:30 -0400 Received: from mail-ie0-f172.google.com ([209.85.223.172]:35213 "EHLO mail-ie0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750839AbbEAQ41 (ORCPT ); Fri, 1 May 2015 12:56:27 -0400 Message-ID: <5543B037.9070504@plumgrid.com> Date: Fri, 01 May 2015 09:56:23 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ingo Molnar , Peter Zijlstra CC: Wang Nan , davem@davemloft.net, acme@kernel.org, mingo@redhat.com, masami.hiramatsu.pt@hitachi.com, jolsa@kernel.org, lizefan@kernel.org, linux-kernel@vger.kernel.org, pi3orama@163.com, hekuang@huawei.com, bgregg@netflix.com Subject: Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs. References: <1430391165-30267-1-git-send-email-wangnan0@huawei.com> <554302F0.3070101@plumgrid.com> <20150501110659.GE5029@twins.programming.kicks-ass.net> <20150501114943.GA24094@gmail.com> In-Reply-To: <20150501114943.GA24094@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 5/1/15 4:49 AM, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> On Thu, Apr 30, 2015 at 09:37:04PM -0700, Alexei Starovoitov wrote: >>> We're also working in parallel on creating a new tracing language >>> that together with llvm backend can be used as a single shared library >>> that can be called from perf or anything else. >> >> Gurgh, please also keep normal C an option. [...] > > Absolutely, I thought there was agreement on that when we started > merging all these eBPF patches ... > > It might be 'simplified C', in that it's just a subset of C, but > please don't re-do something that works, especially if it's used to > instrument a kernel that is written in C ... of course. When did I say that I like 'bird' languages? :) By 'new' I mean that we're not trying to port existing tracing language like dtrace, systemtap, ktap to bpf. I believe dtrace would have been more widely adopted if it didn't invent new syntax. We're trying to do a C -- with ++. It's C where non-supported things like 'for', 'while', 'asm' are actively error-ed by front-end and additional syntactic sugar for things that too ugly/verbose in vanilla C are added. Full C via clang will always be there, but looks like it will have a hard time, because full C has way too many things that are not supported by bpf VM. We're trying to act on feedback that new users are giving us. It's much more friendly when compiler tells you right away that 'for' is not supported instead of kernel verifier says that there is a loop. New thing is map[key] access which is equivalent to bpf_map_lookup(&map, &key) followed by bpf_map_update(&map, &key, &zero_value) if lookup doesn't find an element. Turned out that for tracing use cases it's a very common pattern. Anyway, back to my original question about long term home. where to land 'perf/bpf' branch ? I also agree on a room for additional arguments after 'perf bpf'. Especially I like to see 'perf bpf list'.