From owner-freebsd-net@FreeBSD.ORG  Mon Aug  5 19:57:06 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 566741E2
 for <freebsd-net@freebsd.org>; Mon,  5 Aug 2013 19:57:06 +0000 (UTC)
 (envelope-from rmind@netbsd.org)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 4310C23E4
 for <freebsd-net@freebsd.org>; Mon,  5 Aug 2013 19:57:06 +0000 (UTC)
Received: from ws (localhost [IPv6:::1])
 by mail.netbsd.org (Postfix) with SMTP id F276A14A1A7;
 Mon,  5 Aug 2013 19:57:04 +0000 (UTC)
Date: Mon, 5 Aug 2013 20:56:46 +0100
From: Mindaugas Rasiukevicius <rmind@netbsd.org>
To: christos@astron.com (Christos Zoulas)
Subject: Re: BPF_MISC+BPF_COP and BPF_COPX
In-Reply-To: <ktna5b$275$1@ger.gmane.org>
References: <20130804191310.2FFBB14A152@mail.netbsd.org>
 <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com>
 <ktna5b$275$1@ger.gmane.org>
X-Mailer: mail(1)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20130805195704.F276A14A1A7@mail.netbsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2013 19:57:06 -0000

christos@astron.com (Christos Zoulas) wrote:
> >> <...>
> >> 
> >> 	BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */
> >> 
> >> 	typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt,
> >> 	    uint32_t A, uint32_t *M);
> >> 
> >> 	int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n);
> >> 
> >> <...>
> 
> Well, aside from the consideration that somehow bpf needs to understand
> what memory locations the coproc function alters (so that it considers
> them initialized), the bigger question is how does the code for those
> functions gets loaded and unloaded, and which bpf programs have access to
> those functions.

This is not really for /dev/bpf.  The user would be a kernel subsystem,
which would call bpf_filter(9) on a packet (or whatever is stored in the
mbuf) itself.  As it would provide/control both the byte-code and the
coprocessor functions, the calling convention (e.g. callee/caller words
in the memory store) would be consistent.

Hence the need to adjust bpf_filter() routine to accept struct bpf_ctx
which would contain the coprocessor routines.  While doing that, I would
also like to add support for initialising the memory store words to a
custom values.

> 
> christos
> 

-- 
Mindaugas