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

Instruction stack data structure #14

Open
alex-dukhno opened this issue Mar 5, 2017 · 1 comment
Open

Instruction stack data structure #14

alex-dukhno opened this issue Mar 5, 2017 · 1 comment

Comments

@alex-dukhno
Copy link

Working on #6, looking at #10, #9 and #8. I see that we have a lack of high-level stack of bpf instructions.
Personally, I see it as the following:

struct InsnStack {
   head: RefToInsn // points on the first instruction that will be executed
   tail: RefToInsn // points on `exit` instuction, unless it is an invalid bpf program
}

impl InsnStack {
   pub fn create() -> Self {
       //...
   }

   pub fn disassemble() -> String {
       //...
   }

   //may be a bunch of functions from #6 ... I am ok if we remove `insn_builder` module

   pub fn patch(patch: MbuffStructure) {
       //...
   }

   pub fn validate() -> Result<ValidInsnStack, ValidationError> { // <- the same as InsnStack but `tail` always points to `exit` Insn :smile:
       //...
   }
}

pub fn parse_assemble(raw_bpf_asm: String) -> InsnStack {
   //...
}

RefToInsn can be any type of reference, however, we could not use Box here.
Having that structure we can provide API to easily manipulate its content.

@qmonnet, thoughts?

PS1: again as in #12 we need to do some prototype here.
PS2: I also don't like that we have the bunch of different structures that in some or other way represent bpf instruction, but I don't see the solution to this problem right now.

@qmonnet
Copy link
Owner

qmonnet commented Mar 5, 2017

Hi, having this kind of structure to unify program handling seems a good thing. Thanks for proposing!

Apart from the .patch() use case—for which we might have to change the number of instructions if we ever get something good enough in the future—what would we earn with a stack over some vector / array of instructions as we had this far?

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

No branches or pull requests

2 participants