On Wed, Oct 31, 2018 at 11:52 AM Dan Siemon <d...@coverfire.com> wrote: > > On Wed, 2018-10-31 at 11:42 -0700, Alexei Starovoitov wrote: > > On Wed, Oct 31, 2018 at 11:36 AM Dan Siemon <d...@coverfire.com> > > 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' -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1512): https://lists.iovisor.org/g/iovisor-dev/message/1512 Mute This Topic: https://lists.iovisor.org/mt/27808558/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
