Re: BPF_MISC+BPF_COP and BPF_COPX

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

Mindaugas Rasiukevicius wrote:
> Why is it a problem?  Given that the byte-code and the functions would come
> from the same source, some coupling seems natural to me.  It is simplistic
> anyway: some already parsed offsets or values could be passed through the
> memory store.

You surely have some picture in mind but I can't get it. I'm a bit
worried that two different environments may look unnatural when married
together.
Perhaps, you should right a proposal with some use-cases to support your
points.

> > 
> > Ah, you plan to generalize scratch memory. It's probably fine but don't
> > generalize too many things because people (me at least) want to be able
> > to recognize the original bpf and its orignal design.
> 
> Well, you suggested getter/setter. :)

Yeah, please write a proposal ;-)

> > Please note that I allocate scratch memory on the stack in bpfjit.
> > If you change scratch memory to be under bpf_ctx, you will need to
> > reimplement quite a lot in bpfjit code.
> 
> Is it really a lot?  We can waste some cycles and just copy them into the
> stack (if there are any initial values).

Not really a lot given a size of bpfjit.c but if you hit some limitation
of sljit, be prepared to do extra coding to work around it.

Alex