linux-kernel - Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 01 May 2015 09:56:23 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
CC:	Wang Nan <wangnan0@...wei.com>, davem@...emloft.net,
	acme@...nel.org, mingo@...hat.com, masami.hiramatsu.pt@...achi.com,
	jolsa@...nel.org, lizefan@...nel.org, linux-kernel@...r.kernel.org,
	pi3orama@....com, hekuang@...wei.com, bgregg@...flix.com
Subject: Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to
 load eBPF programs.

On 5/1/15 4:49 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra <peterz@...radead.org> 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'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/