From owner-freebsd-hackers Mon Oct 20 16:52:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA29596 for hackers-outgoing; Mon, 20 Oct 1997 16:52:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA29589 for ; Mon, 20 Oct 1997 16:52:07 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id QAA04335; Mon, 20 Oct 1997 16:51:51 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd004333; Mon Oct 20 16:51:50 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA27105; Mon, 20 Oct 1997 16:51:43 -0700 (MST) From: Terry Lambert Message-Id: <199710202351.QAA27105@usr05.primenet.com> Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd) To: darrenr@cyber.com.au (Darren Reed) Date: Mon, 20 Oct 1997 23:51:43 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199710190548.PAA19493@plum.cyber.com.au> from "Darren Reed" at Oct 19, 97 03:48:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > well, ifconfig, netstat, etc. all need it. They reference kernel internal structures as an API. > > > if you're writing your own LKM for a network driver, you need it. LKM code is kernel code. Kernel code can have any requirements that the kernel environment chooses to place on it (one of which is what include files are necessary). > > > if you're writing firewalling packet filtering code, you need it. Again, kernel code. > > > "struct ifnet" is used in _lots_ of places. Not lots of places outside kernel code. > > > if you want to simulate kernel code, then you also need it. [ ... ] > What if I mention this: > > I was using "struct ifnet" _WITHOUT_ wanting to look at kernel memory. > > > Why would you want to do that, you ask. > > So you can more easily build userland code which interfaces with the > code used in the kernel and test it that way. In other words, unit testing. I'd claim that your test framework must include whatever the kernel includes, in order to properly simulate a kernel. Further, the code you are unit testing in this fashion is -- kernel code. I don't see this as being inconvenient except for users of "promiscuous" interfaces (like your examples: ifconfig, netstat, etc.). I personally *like* the idea of a "speed-bump" to slow down people going hell bent for leather down the wrong road to an interface... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.