Date: Mon, 3 Dec 2012 12:11:34 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: "Alexander V. Chernikov" <melifaro@FreeBSD.org> Cc: freebsd-ipfw@FreeBSD.org, Hiroki Sato <hrs@FreeBSD.org>, delphij@FreeBSD.org, "freebsd-net@freebsd.org" <freebsd-net@FreeBSD.org> Subject: Re: [CFT] Virtual BPF interfaces (was: CFR: ipfw0 pseudo-interface clonable) Message-ID: <20121203081134.GO14202@glebius.int.ru> In-Reply-To: <50BAA552.1010707@FreeBSD.org> References: <4F96D11B.2060007@FreeBSD.org> <20120425.020518.406495893112283552.hrs@allbsd.org> <4F96E71B.9020405@FreeBSD.org> <20120427.084414.1142593201575277510.hrs@allbsd.org> <4FD4AD29.3040204@FreeBSD.org> <50BAA552.1010707@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 02, 2012 at 04:48:18AM +0400, Alexander V. Chernikov wrote: A> On 10.06.2012 18:20, Alexander V. Chernikov wrote: A> > On 27.04.2012 03:44, Hiroki Sato wrote: A> >> "Alexander V. Chernikov"<melifaro@FreeBSD.org> wrote A> >> in<4F96E71B.9020405@FreeBSD.org>: A> >> A> >> me> On 24.04.2012 21:05, Hiroki Sato wrote: A> > A> > Proof-of-concept patch attached. A> A> Hopefully, libcap code is easily extendable. A> New version attached: A> * BPF code is now able to use 'virtual' interfaces without real ifnet A> * New bpfattach3() / bpfdetach3() routines were added to attach virtual A> ifaces A> * New BIOCGIFLIST ioctl is added to permit userland to retrieve A> available virtual interfaces A> * freebsd-specific 'platform_finddevs' version is added to libpcap code A> (new file) A> A> There are some rough edges (conditional code in pcap-bpf.c, lack of A> documentation, maybe some style issues), but generally it seems to work A> and does not interfere with contrib/ code much (from my point of view). A> A> ipfw log device was converted to use new bpf(4) api, see attached patch. Nice proof of concept, Alexander! What does prevent us from unifing all bpf providers to be "virtual" in current terms? I think if we finish divorce between ifnet and bpf, the code would get simplier and you can proceed further with reducing locking overhead. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121203081134.GO14202>