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 _______________________________________________ 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"
