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?

Thanks.

On Wed, Oct 31, 2018 at 11:36 AM Dan Siemon <dan@...> wrote:

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?

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@...>
wrote:

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?

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.

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:

On Wed, 2018-10-31 at 11:42 -0700, Alexei Starovoitov wrote:

On Wed, Oct 31, 2018 at 11:36 AM Dan Siemon <dan@...>
wrote:

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?

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.

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.

please define 'unsafe'

On Wed, 2018-10-31 at 11:53 -0700, Alexei Starovoitov 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.

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.

please define 'unsafe'

Not Go in the Go runtime :)