From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 20:18:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 835CFC41 for ; Wed, 7 Aug 2013 20:18:26 +0000 (UTC) (envelope-from alnsn@yandex.ru) Received: from mail.o2.co.uk (jabba.london.02.net [82.132.130.169]) by mx1.freebsd.org (Postfix) with ESMTP id 48E24267A for ; Wed, 7 Aug 2013 20:18:25 +0000 (UTC) Received: from localhost (78.86.33.51) by mail.o2.co.uk (8.5.140.03) (authenticated as nasonov) id 51DA940306009A93; Wed, 7 Aug 2013 21:17:12 +0100 Date: Wed, 7 Aug 2013 21:17:12 +0100 From: Alexander Nasonov To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130807201712.GA2042@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> <20130807174701.9E1C214A0F7@mail.netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130807174701.9E1C214A0F7@mail.netbsd.org> X-Operating-System: Linux 3.4.0 on armv7l X-SHELL: /bin/bash X-FCEDIT: /bin/ed X-EDITOR: /usr/bin/vi X-VISUAL: vim User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:18:26 -0000 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