Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chained API for assemble / verify / run BPF programs #12

Open
alex-dukhno opened this issue Feb 21, 2017 · 3 comments
Open

Chained API for assemble / verify / run BPF programs #12

alex-dukhno opened this issue Feb 21, 2017 · 3 comments

Comments

@alex-dukhno
Copy link

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

@qmonnet
Copy link
Owner

qmonnet commented Feb 21, 2017

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.

@alex-dukhno
Copy link
Author

“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 😄

@badboy
Copy link
Collaborator

badboy commented Feb 22, 2017

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants