From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754037AbbCCCb3 (ORCPT ); Mon, 2 Mar 2015 21:31:29 -0500 Received: from mail-qg0-f44.google.com ([209.85.192.44]:34654 "EHLO mail-qg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753529AbbCCCb1 (ORCPT ); Mon, 2 Mar 2015 21:31:27 -0500 MIME-Version: 1.0 From: Alexei Starovoitov Date: Mon, 2 Mar 2015 18:31:06 -0800 Message-ID: Subject: Re: [PATCH v2 00/15] tracing: 'hist' triggers To: Tom Zanussi Cc: Steven Rostedt , Masami Hiramatsu , Namhyung Kim , Andi Kleen , LKML , Ingo Molnar , Arnaldo Carvalho de Melo Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 2, 2015 at 5:18 PM, Tom Zanussi wrote: >> >> I'm saying keep the command line version of hist, but let >> user space process it. >> I don't buy the argument that you must run it in busybox >> without any extra tools. >> If you're in busybox, the system is likely idle, so nothing >> to trace/analyze. If you have some user space apps, >> then it equally easy to add 'hist->bpf' tool. >> > > How about systems that run a single statically linked process with no > shell (but a service that can read and write files like/event/trigger > and event/hist)? We'd still like to be able to trace those systems. hmm, there is no shell and one cannot do 'echo hist.. > trigger; cat hist' , but there is a demon that can accept remote commands ? Then would make even more sense to pass bpf programs from remote host and consume aggregated data remotely. This on-host demon will be tiny wrapper on top of bpf syscall. Quite a bit more flexible :) > Well, I'd say writing BPF 'assembly' to do anything isn't something more > than a few users in the world would even consider, so that's completely > out. Which means the only practical way to use it is via the C > interface. But getting that set up properly doesn't seem > straightforward either - it isn't something the Makefile will help with, > and there's no documentation on how one might do it. I'm not proposing to use asm or C for this 'hist->bpf' tool. Keep proposed 'hist:keys=...:vals=...' syntax and generate bpf program on the fly based on this string. So this user tool will take string, generate program, load and attach it. Everything based on this single string input. With the examples you mentioned in docs, it's not hard. It will be more involved than patch 12, but way more generic and easily extensible when 'hist:keys=...' string would need to be extended. > So I tweaked the Makefile to get samples/bpf in the build (I mean the > directory is there under samples/, so why do I need to add it to the > Makefile myself?) and tried building which failed until I tweaked > something else to get it to find the right headers, etc. Finally I got > it building the userspace stuff but then found out I needed my own llvm > to get the kernel modules built, so searched and found your llvm tree > which I thought would configure the bpf backend automatically, but > apparently not, since it then failed with llc: invalid target 'bpf' > which is where I gave up. Do I need to configure with --target=bpf or > something like that? I don't know, and know nothing about llvm, so am > kind of stuck. hmm. 'make samples/bpf/' should work out of the box. only llvm needs to installed. To install llvm: $git clone http://llvm.org/git/llvm.git $mkdir llvm/bld; cd llvm/bld if you like cmake: $cmake -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF .. $make if you like autoconf: $../configure --enable-experimental-targets=BPF $make That's typical for any new backend. Hopefully soon it will lose 'experimental' status. > I really do want to try doing something with it, and I understand that > you're working on improving the user experience, but at this point it > seems users have to jump through a lot of hoops just to get a minimally > working setup. Even a small paragraph with some basic instructions > would help. Or maybe it's just me, and it works for everyone else out > of the box. Thank you for feedback. We'll add llvm build instructions to the doc. The goal for llvm is to be able to do 'apt-get install llvm-3.7' and bpf will be part of default install.