Alexander Nasonov <al...@yandex.ru> wrote: > 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.
OK, but you did not explain why is it a problem i.e. why is it worrying? > Perhaps, you should right a proposal with some use-cases to support your > points. They are simple: consider detecting IP version and calculating the offset to L4 header. There is no reason to duplicate this work in the byte-code and the coprocessor. If one of them does it - let's just save 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. :) > > Yeah, please write a proposal ;-) > int bpf_get_memword(const bpf_ctx_t *c, size_t i, uint32_t *val); int bpf_set_memword(bpf_ctx_t *c, size_t i, uint32_t val); You prefer something like this? -- 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"