Re: BPF_MISC+BPF_COP and BPF_COPX

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

Mindaugas Rasiukevicius wrote:
> Yes, I may want to keep the state in the memory store or pass the arguments
> through it, since the accumulator might not be enough.

You have access to a whole packet, why do you need to pass additional
arguments through the store? I'm worried about introducing tight
coupling between these two very different environments and adding
"sugar" for easy interaction is a big step in this direction.

> If you prefer getter
> and setter to perform a boundary check and enforce uint32_t type, I am fine
> with that.  Although BPF_MEMWORDS constant and words storing 32-bit values
> stayed since 80s.. it is not going to change.
> 
> However, abusing void * is wrong.  Once bpf_filter(9) is adjusted to take
> an opaque struct bpf_ctx *, the memory store ought to be moved into it.

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.

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.

> The rationale behind it is that we might want to handle out-of-range in the
> byte-code without breaking the flow.  This can be a valid case for BPF_COPX.
> Just BPF_RET 0 seems a limitation, but I do not have a strong feeling here.

I'd keep it consistent with bpf.

Alex