Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754346AbbFEGlZ (ORCPT ); Fri, 5 Jun 2015 02:41:25 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:35037 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751149AbbFEGlV (ORCPT ); Fri, 5 Jun 2015 02:41:21 -0400 Date: Fri, 5 Jun 2015 08:41:14 +0200 From: Ingo Molnar To: Alexei Starovoitov Cc: pi3orama , "Wangnan (F)" , Arnaldo Carvalho de Melo , "linux-kernel@vger.kernel.org" , Adrian Hunter , Brendan Gregg , Daniel Borkmann , David Ahern , He Kuang , Jiri Olsa , Kaixu Xia , Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , Namhyung Kim , Peter Zijlstra , Sukadev Bhattiprolu , Zefan Li , Arnaldo Carvalho de Melo , Alexei Starovoitov Subject: Re: [GIT PULL 0/6] perf/core improvements and fixes Message-ID: <20150605064114.GA18341@gmail.com> References: <1433371238-14572-1-git-send-email-acme@kernel.org> <20150604054854.GA10969@gmail.com> <556FEB32.8040909@huawei.com> <20150604072153.GA18983@gmail.com> <557021D3.7070900@huawei.com> <20150604124033.GA10580@gmail.com> <0108CD89-BFFA-4A68-90AE-A34597777641@163.com> <20150604140412.GB14445@gmail.com> <55707B3F.2070704@plumgrid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55707B3F.2070704@plumgrid.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 Content-Length: 4445 Lines: 114 * Alexei Starovoitov wrote: > On 6/4/15 7:04 AM, Ingo Molnar wrote: > >>> # perf record -e bpf_source.c cmdline > >>> > >>> to create a eBPF filter from source, > >>> > >>>Use > >>> > >>># perf record -e bpf_object.o cmdline > >>> > >>>to create a eBPF filter from object intermedia. > >>> > >>>Use > >>> > >>># perf bpf compile bpf_source.c --kbuild=kernel-build-dir -o bpf_object.o > >>> > >>>to create the .o > >>> > >>>I think this should be enough. Currently only the second case has been implemented. > > > > So if users cannot actually generate .o files then it's premature to merge > > this in such an incomplete form! > > > > It should be possible to use a feature that we are merging. > > of course it's usable :) There is some confusion here. > To compile .c into .o one can easily use > clang -O2 -emit-llvm -c file.c -o - | llc -march=bpf -o file.o There's no confusion here: you guys are trying to sell me what at this stage is incomplete and hard to use, and I'm resisting it as I should! :-) We also have different definitions of 'easily'. It might be 'easy' to type: clang -O2 -emit-llvm -c file.c -o - | llc -march=bpf -o file.o ... for some tooling developer intimate with eBPF, but to the first time user who found an interesting looking eBPF scriptlet on the net or in the documentation and wants to try his luck? It's absolutely non-obvious! The current usage to get a _minimal_ eBPF script running is non-obvious and obscure to the level of being a show stopper. I don't understand why you guys are even wasting time arguing about it: it's not that hard to auto-build from source code. It's one of the basic features of tooling. If you ever built perf you'll know that typing 'make install' will type in all those quirky build lines automatically for you, without requiring you to perform any other step, no matter how trivial. Doubly annoying, you seem to have the UI principles wrong, you seem to think that a .o is a proper user interface. It absolutely is _not_ okay. The Linux kernel project and as an extension the perf project deals with source code, and I'm 100% suspicious of approaches that somehow think that .o objects are the right UI for _anything_ except temporary files that sometimes show up in object directories... Fix the 'newbie user' UI flow as a _first_ priority, not as a second thought! Every single quirky line or nonsensical option you require a first time user to type halves the number of new users we'll get. You need to understand why dtrace is so popular: - it's bloody easy to use - it's a safe environment you can deploy in critical environments - it's flexible - instrumentation hacks are very easy to share eBPF based scripting got 3 out of those 4 right, but please don't forget item 1 either, because without that we have nothing but a bunch of unusable functionality in the kernel and in tooling that benefits only very few people. Okay? > So I think we need to support both 'perf record -e file.[co]' Why do you even need to ask? Of course! Think through how users will meet eBPF scripts and how they will interact with them: - they'll see or download an eBPF scriptlet somewhere and will have a .c file. - ideally there will be built-in eBPF scriptlets just like we have tracing plugins, and there's a good UI to query them and see their description and source code. - then they will want to use it all with the minimum amount of fuss - they don't care how the eBPF scriptlet gets to the kernel: whether the kernel can read and build the .c files, or whether there's some user tooling that turns it into bytecode. Most humans don't read bytecode! - they will absolutely not download random .o's and we should not encourage that in any case - these things should be source code based. These things compile in an eye blink, there's very little reason to ever deal with a .o, except some weird and rare usecases... In fact I'm NAK-ing the whole .o based interface until the .c interface is made the _primary_ one and works well and until I see that you have thought through basic usability questions... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/