On Wed, Oct 31, 2018 at 11:52 AM Dan Siemon <dan@...> wrote:
On Wed, 2018-10-31 at 11:42 -0700, Alexei Starovoitov wrote:
On Wed, Oct 31, 2018 at 11:36 AM Dan Siemon <dan@...>Correct. No BTF, I mostly had bpf calls going but didn't finish it
I was on the IOVisor call, there was discussion of making thereasonably simple? ;)
more complicated (perf stuff) and work on libbpf to support this.
this refer to doing the relocations etc in the ELF file?
We have our own loader written in Go for our bpf classifier use
so I'm curious what these changes may mean for us. The current
implementation was reasonably simple. Is the expectation going
that libbpf is always used? Will other implementations need to
and duplicate this complexity or is this backwards compatible?
I suspect it doesn't support bpf-to-bpf calls and BTF, right?
These were major additions that folks with custom loader
will be missing.
A lot more stuff to come with BTF, relocations, etc.
I don't think it will be feasible to replicate the same functionality
in other libraries.
Hence everyone is highly encouraged to use libbpf.
c++, go or any other wrappers can go on top.
Whether they're kept as part of libbpf repo or repo next to it is
because we don't need it right now.
I understand the situation but this makes me a bit sad. I wrote the
loader originally to avoid 'unsafe' code in our project.
please define 'unsafe'