Alexander Nasonov <al...@yandex.ru> 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.
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. > > 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. Well, you suggested getter/setter. :) > 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). -- Mindaugas _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
