Thread (78 messages) flat view 78 messages, 7 authors, 2014-08-19

Re: [PATCH RFC v4 net-next 17/26] tracing: allow eBPF programs to be attached to events

From: Alexei Starovoitov <hidden>
Date: 2014-08-15 19:16:17
Also in: lkml, netdev

On Fri, Aug 15, 2014 at 12:02 PM, Andy Lutomirski [off-list ref] wrote:
quoted
correct. eBPF program would be using 8-byte read on 64-bit kernel
and 4-byte read on 32-bit kernel. Same with access to ptrace fields
and pretty much all other fields in the kernel. The program will be
different on different kernels.
Say, this bpf_context struct doesn't exist at all. The programs would
still need to be different to walk in-kernel data structures...
Hmm.  I guess this isn't so bad.

What's the actual difficulty with using u64?  ISTM that, if the clang
front-end can't deal with u64, there's a bigger problem.  Or is it
something else I don't understand.
clang/llvm has no problem with u64 :)
This bpf_context struct for tracing is trying to answer the question:
 'what's the most convenient way to access tracepoint arguments
from a script'.
When kernel code has something like:
 trace_kfree_skb(skb, net_tx_action);
the script needs to be able to access this 'skb' and 'net_tx_action'
values through _single_ data structure.
In this proposal they are ctx->arg1 and ctx->arg2.
I've considered having different bpf_context's for every event, but
the complexity explodes. I need to hack all event definitions and so on.
imo it's better to move complexity to userspace, so program author
or high level language abstracts these details.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help