This group is locked. No changes can be made to the group while it is locked.
Date 1 - 5 of 5
|1 - 5 of 5|
I was on the IOVisor call, there was discussion of making the loader
more complicated (perf stuff) and work on libbpf to support this. Does
this refer to doing the relocations etc in the ELF file?
We have our own loader written in Go for our bpf classifier use cases
so I'm curious what these changes may mean for us. The current
implementation was reasonably simple. Is the expectation going forward
that libbpf is always used? Will other implementations need to track
and duplicate this complexity or is this backwards compatible?
On Wed, Oct 31, 2018 at 11:36 AM Dan Siemon <dan@...> wrote:
reasonably simple? ;)
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 tbd.
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
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.
On Wed, Oct 31, 2018 at 11:52 AM Dan Siemon <dan@...> wrote:
please define 'unsafe'
On Wed, 2018-10-31 at 11:53 -0700, Alexei Starovoitov wrote:
Not Go in the Go runtime :)please define 'unsafe'Correct. No BTF, I mostly had bpf calls going but didn't finish it
|1 - 5 of 5|