Date: Tue, 7 Jun 2005 12:23:40 +0100 From: Bruce M Simpson <bms@spc.org> To: Matthew Luckie <mjl@luckie.org.nz> Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device Message-ID: <20050607112340.GC812@empiric.icir.org> In-Reply-To: <20050607101927.GA99034@lycra.luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 07, 2005 at 10:19:29PM +1200, Matthew Luckie wrote: > Please review. This is good and useful work. It looks like something which has been in need of cleanup for a while. Unfortunately my current situation re resources (time and infrastructure) means that whilst I can review and commit code it's difficult for me to test it (unless it's userland) hopefully this will improve in the next week or two. I'd be wary of changing the definition of DLT_NULL however -- it literally means 'there's nothing here apart from raw data', and changing this notion would mean that we have to change it everywhere, including bpf clients, because the change being proposed would make DLT_NULL mean 'there's a 32-bit integer in front of everything else which is raw data', which is something else. I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to get review for the change from the NetBSD and OpenBSD guys too, as well as the tcpdump.org guys. Looking at style, it might be better if the driver(s) were changed to explicitly use a 32-bit wide int type such as u_int32_t for the address family header field in their bpfattach() calls. ICHDRLEN is odd man out, but it is #define'd to be the same thing; I would update it there also. A white space pass should probably also be done last thing to be sure. I have no idea about ng_sppp.c I'm afraid. It helps my dayjob because we're currently looking at what it would take to integrate a code drop of the IS-IS routing protocol by one of our students -- unfortunately to remain backwards compatible with existing IS-IS deployments out there, we need to be able to speak link layer IS-IS as well as IPv4 encapsulated IS-IS. Of course to do this, we need bpf write support for the appropriate link layers. The more link layers we have support for bpf writes, particularly across the software loopback and tunnel type links, the better it is for testing and integration, as well as running IS-IS directly over a VPN on FreeBSD. Thanks, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050607112340.GC812>