Hi all, On Thu, Nov 17, 2016 at 5:54 AM, Brenden Blanco via iovisor-dev <[email protected]> wrote: [...] > Alban: > Had 4 topics from IRC (3 were discussed): > 1. Golang libraries for kprobe-eBPF and perf-maps > We agreed to fork the code in github.com/iovisor/iomodules into its own > go library. > AI: Brenden to send proposal for name of new repo > 2. dependencies on kernel headers for kprobe-eBPF > There has been some previous discussion of this in > github.com/iovisor/bcc/issues/421, but no substantial progress yet. Another > alternative that Brenden proposed was to let the API accept LLVM-IR as the > input of a BPF() object, such that frontends could "compile" against the > headers offline. > 3. API stability for a limited set of kprobe-eBPF programs > We didn't discuss this, Alban would you like to give us some more context?
I forgot this part. I am using kprobes / kretprobes on the following functions: - tcp_v4_connect - tcp_close - inet_csk_accept And I access the following structs (& fields): - struct sock (__sk_common) - struct sock_common (skc_rcv_saddr, skc_daddr, skc_dport, skc_num, skc_net) - struct inet_sock (inet_sport) - struct ns_common (inum) If I compile the eBPF program once and reuse it for future kernel, how likely is it that the used fields will change offsets and things might break? If I want to support several kernels (let's say the last Ubuntu, Fedora, ... kernels), how likely is it that the offsets of the fields above don't change and that I could reuse one pre-compiled eBPF program for several kernels? > 4. size of bcc.so when included in (and used from within) a container image > wanting to build libbcc against alpine go bindings > No work has been done to compile bcc using alpine base. This would be a > nice > to have if someone out there has some experience or free time. Cheers, Alban _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
