4 ms·

My biggest grievance with BCC has been, as noted in the article, that it requires LLVM to be linked in. Also, it requires a Python interpreter on the target mac

by any1 8y ago

My biggest grievance with BCC has been, as noted in the article, that it requires LLVM to be linked in. Also, it requires a Python interpreter on the target machine. I've also wondered why eBPF can't be pre-compiled. Installing those dependencies on a regular PC is easy, but not so on an embedded system. I tried cross-compiling the dependencies once, but got stuck at some point. It would've been hard to justify the time spent if I'd continued, so I dropped it. I'm really happy that someone has invested time into this issue.

vavrusa 8y ago
I wrote a not very well known LuaJIT to BPF compiler as a part of bcc precisely because of this. It doesn't depend on anything besides LuaJIT (no LLVM, no C, no libbpf, etc). Caveats: it's Lua, it doesn't fast track all the latest from bcc as it's a "for fun" project. https://github.com/iovisor/bcc/tree/master/src/lua#luajit-bpf-compiler https://github.com/iovisor/bcc/tree/master/src/lua#luajit-bp...
- any1 8y ago
  Thanks for sharing this, I will look into it. We have luajit on our system so this might be just what I need.
kupiakos 8y ago
One of the big reasons is that if you're using kernel headers and internal structures, like with kprobes, they're unstable APIs, and the struct offsets may change between kernel versions. You can compile for each kernel type you're going to use, but that is more effort and foresight. There's also the rewriting of map file descriptors in the bytecode itself on load time, but libbpf generally handles this.
- any1 8y ago
  I do not think that I would mind so much having to re-compile between kernel versions if it's just a matter of running "make" and copying the binaries to the target.
coredog64 8y ago
I spent a good chunk of my Christmas break last year trying to get LLVM and bcc working on Amazon Linux without any success. So it can be difficult even on a non-embedded system.

by any1 8y ago

vavrusa 8y ago

I wrote a not very well known LuaJIT to BPF compiler as a part of bcc precisely because of this. It doesn't depend on anything besides LuaJIT (no LLVM, no C, no libbpf, etc). Caveats: it's Lua, it doesn't fast track all the latest from bcc as it's a "for fun" project. https://github.com/iovisor/bcc/tree/master/src/lua#luajit-bpf-compiler https://github.com/iovisor/bcc/tree/master/src/lua#luajit-bp...

any1 8y ago
Thanks for sharing this, I will look into it. We have luajit on our system so this might be just what I need.

kupiakos 8y ago

One of the big reasons is that if you're using kernel headers and internal structures, like with kprobes, they're unstable APIs, and the struct offsets may change between kernel versions. You can compile for each kernel type you're going to use, but that is more effort and foresight. There's also the rewriting of map file descriptors in the bytecode itself on load time, but libbpf generally handles this.

any1 8y ago
I do not think that I would mind so much having to re-compile between kernel versions if it's just a matter of running "make" and copying the binaries to the target.

coredog64 8y ago

I spent a good chunk of my Christmas break last year trying to get LLVM and bcc working on Amazon Linux without any success. So it can be difficult even on a non-embedded system.