linux-kernel - Re: [RFC PATCH v3 06/37] bpf tools: Introduce 'bpf' library to tools

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <555E1B90.2010809@plumgrid.com>
Date:	Thu, 21 May 2015 10:53:20 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	"Wangnan (F)" <wangnan0@...wei.com>, paulus@...ba.org,
	a.p.zijlstra@...llo.nl, mingo@...hat.com, acme@...nel.org,
	namhyung@...nel.org, jolsa@...nel.org, dsahern@...il.com,
	daniel@...earbox.net, brendan.d.gregg@...il.com,
	masami.hiramatsu.pt@...achi.com
CC:	lizefan@...wei.com, linux-kernel@...r.kernel.org, pi3orama@....com
Subject: Re: [RFC PATCH v3 06/37] bpf tools: Introduce 'bpf' library to tools

On 5/20/15 5:24 PM, Wangnan (F) wrote:
>
>
> Do you think we should classify kprobe/socket programs in libbpf layer
> instead of perf?
>
> In my current implementation, type of a program is determined by perf by
> parsing names of
> corresponding sections. Format of section names should be part of
> interface between perf
> (and iproute2 and others) and eBPF programs. What libbpf should do is to
> fetch those
> names and give them to caller, let caller decide the type of programs.
> Therefore, if
> the program is written for perf, writer of program even don't need to
> think about
> kprobe/socket program type since in perf currently we can only use
> kprobe program.

if whole section name string is passed to perf/iproute2 then it's fine,
but libbpf already parses 'map', 'license', 'version' section names.
Are you saying everything else will be passed to perf directly?
perf will parse section string, generate extra prologue insns based on
debug info found in vmlinux and call into library back to load them?
Sounds ok-ish. Let's see how code looks.

--
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/