Date: Wed, 7 Aug 2013 21:17:12 +0100 From: Alexander Nasonov <alnsn@yandex.ru> To: Mindaugas Rasiukevicius <rmind@netbsd.org> Cc: tech-net@netbsd.org, freebsd-net@freebsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130807201712.GA2042@x1000.localdomain> In-Reply-To: <20130807174701.9E1C214A0F7@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> <20130807174701.9E1C214A0F7@mail.netbsd.org>
index | next in thread | previous in thread | raw e-mail
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. Alexhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807201712.GA2042>