Topics

Loader complexity

Dan Siemon
 

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.

Alexei Starovoitov
 

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.

Dan Siemon
 

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.

Alexei Starovoitov
 

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'

Dan Siemon
 

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 :)