Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Aug 2013 18:46:41 +0100
From:      Mindaugas Rasiukevicius <rmind@netbsd.org>
To:        Alexander Nasonov <alnsn@yandex.ru>
Cc:        tech-net@netbsd.org, freebsd-net@freebsd.org
Subject:   Re: BPF_MISC+BPF_COP and BPF_COPX
Message-ID:  <20130807174701.9E1C214A0F7@mail.netbsd.org>
In-Reply-To: <20130806065903.GA2835@x1000.localdomain>
References:  <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain>

next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Nasonov <alnsn@yandex.ru> wrote:
> > Yes, I may want to keep the state in the memory store or pass the
> > arguments through it, since the accumulator might not be enough.
> 
> You have access to a whole packet, why do you need to pass additional
> arguments through the store? I'm worried about introducing tight
> coupling between these two very different environments and adding
> "sugar" for easy interaction is a big step in this direction.

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.

> > If you prefer getter
> > and setter to perform a boundary check and enforce uint32_t type, I am
> > fine with that.  Although BPF_MEMWORDS constant and words storing
> > 32-bit values stayed since 80s.. it is not going to change.
> > 
> > However, abusing void * is wrong.  Once bpf_filter(9) is adjusted to
> > take an opaque struct bpf_ctx *, the memory store ought to be moved
> > into 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. :)

> 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).

-- 
Mindaugas



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807174701.9E1C214A0F7>