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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807201712.GA2042>