qmonnet / rbpf

Rust virtual machine and JIT compiler for eBPF programs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Chained API for assemble / verify / run BPF programs

alex-dukhno opened this issue · comments

From the #6

PS: working on this API I start thinking about this RawBpfCode and VerifiedBpfCode and let myself create needless functionality. And I understood the reason. It is because my code is OOP-like rather then procedural-like as in the other modules. 😄
I start to imagine that we could write chaining code for BPF program in general. For instance:

let bpf_vm = ... // create VM of any type

RawBpfCode::new().load(...).push().store(...).push()
// or RawBpfCode::parse(...)
// or RawBpfCode::from_elf(...)
.verify().map(|verified| verified.execute_with(bpf_vm)).err().map(...);

and RawBpfCode::parse() can actually use asm_parser functionality to be synched with it.

Taking into account @qmonnet comment:

we already have the “procedural-like” approach that works well, why change it

we can improve procedural API that instead of panic! return Result.
Any thoughts?

cc @badboy @rlane @waywardmonkeys

I am totally in favor of replacing the panic!()s by Results instead, it will be cleaner, in particular if the functions are called from some program bigger than the small examples we have. The assembler does a pretty good job at this. I intended to make the change at some point, I believe that's even in the README. Anyway.

Chaining all the commands is another thing, and I am unsure at this point that it makes it easier to use. My first reaction when looking at your example would be “oh well, what function should I call on the result from this one? Can I keep verification step if I want to? What will I need to call to exec the program several times, with different packets?” etc.

Not saying the idea is bad, either. Maybe that's just me being too conservative here, or needing more time/examples to see how well it would fit.

Since you tagged everyone already… well, I'm open to feedback from other people as well.

“oh well, what function should I call on the result from this one? Can I keep verification step if I want to? What will I need to call to exec the program several times, with different packets?”

Good questions. Haven't thought about them.

Anyway, we need some sort of prototyping here 😄

Hey, just wanted to say that I'm interested in this idea, I just don't have the time this week to follow up. I'll take another look next week (don't hold up on me though)