From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753913AbbERVUU (ORCPT ); Mon, 18 May 2015 17:20:20 -0400 Received: from mail.kernel.org ([198.145.29.136]:37659 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706AbbERVUR (ORCPT ); Mon, 18 May 2015 17:20:17 -0400 Date: Mon, 18 May 2015 18:20:13 -0300 From: Arnaldo Carvalho de Melo To: Alexei Starovoitov Cc: Wang Nan , paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com, namhyung@kernel.org, jolsa@kernel.org, dsahern@gmail.com, daniel@iogearbox.net, brendan.d.gregg@gmail.com, masami.hiramatsu.pt@hitachi.com, lizefan@huawei.com, linux-kernel@vger.kernel.org, pi3orama@163.com Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs. Message-ID: <20150518212013.GB13946@kernel.org> References: <1431860222-61636-1-git-send-email-wangnan0@huawei.com> <555A3FC2.8060805@plumgrid.com> <20150518204416.GJ18563@kernel.org> <555A541F.6090606@plumgrid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555A541F.6090606@plumgrid.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, May 18, 2015 at 02:05:35PM -0700, Alexei Starovoitov escreveu: > On 5/18/15 1:44 PM, Arnaldo Carvalho de Melo wrote: > > > >perf record --filter, to pass a filter to tracepoints, if I could > >instead of a filter expression pass, say, filter_bpf.o, that would seem > >natural for me, i.e. no new option, just an alternative type of filter, > >one way more powerful. > ... > >I'd say keep it in --filter, that noticing it is a bpf object would > >dtrt: > > > > perf record --filter bpf_thing.o usleep 1 > > > > agree. make sense. > The only thing is that such bpf program defines both event and filter. > Existing --filter applies to --event, whereas this bpf_thing.o does both > and likely kprob-ing multiple events underneath. > I guess '--filter' still fits. Just need to document it clearly. Humm, unsure then, because it is not a filter anymore, i.e. it is both a filter and event selector :-\ I was thinking more like, hey, for an existing event, i.e. a place in the kernel where it will collect something, collect if this filter returns true. That would fit the existing --filter semantic. perf record --event bpf_thing.o Looks more natural then, as it is an event that will take place when the filter returns true, and in addition to that, it will come with a bunch of variables, etc. And if that is the case, then what is the difference from a kprobe event? I.e. for the existing tooling it wouldn't matter how this event was set up, as long as it was available via tracefs, etc. I.e. it would be completely similar to a tracepoint, kprobe, uprobe, etc, i.e. first set it up, expose its internals via tracefs, no changes to perf. I must be missing something... But then it would happen when I would try to deal with this eBPF thing, bear with me :-) - Arnaldo