From owner-cvs-all@FreeBSD.ORG Tue Sep 19 19:35:26 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A9716A40F; Tue, 19 Sep 2006 19:35:26 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5708743D58; Tue, 19 Sep 2006 19:35:26 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k8JJZKSX056761; Tue, 19 Sep 2006 15:35:20 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Peter Jeremy Date: Tue, 19 Sep 2006 15:35:06 -0400 User-Agent: KMail/1.6.2 References: <200609182218.k8IMIMUT059300@repoman.freebsd.org> <200609191431.01649.jkim@FreeBSD.org> <20060919190449.GC720@turion.vk2pj.dyndns.org> In-Reply-To: <20060919190449.GC720@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200609191535.08184.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1902/Tue Sep 19 14:44:13 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, John Baldwin Subject: Re: cvs commit: src/sys/dev/bge if_bge.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2006 19:35:27 -0000 On Tuesday 19 September 2006 03:04 pm, Peter Jeremy wrote: > On Tue, 2006-Sep-19 14:30:59 -0400, Jung-uk Kim wrote: > >On Tuesday 19 September 2006 01:52 pm, John Baldwin wrote: > >> Which I'm about to kill hopefully. Please let's fix this the > >> right way and not hack it any further. > > > >Sure, no problem. But I don't think we can DTRT on -STABLE > > without breaking API. Can we? > > I've had a quick look into this problem because I extensively use > VLANs on a bge and discovered that I no longer have VLAN tag > details (which makes packet tracing a nuisance). > > As far as I can see, there is nothing preventing bpf_tap() and > bpf_mtap2() being doctored to undo the VLAN detagging so that > bpf_filter() is passed a mbuf chain that looks like an 802.1Q > ethernet frame: Dummy up an mbuf (as bpf_mtap2() does) that > contains the MAC addresses from the incoming data followed by > the 802.1Q packet type and tag information, with m_next pointing > to the byte after the MAC addresses in the original data. Why don't we just fake it up from ether_input() and pass it to BPF_MTAP() instead of 'teaching' bpf? I think it is more logical thing to do. Jung-uk Kim