From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 17:57:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8383A37B401; Mon, 7 Apr 2003 17:57:54 -0700 (PDT) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5FD843F85; Mon, 7 Apr 2003 17:57:52 -0700 (PDT) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h381AL916921; Mon, 7 Apr 2003 21:10:22 -0400 (EDT) (envelope-from geoff@speicher.org) Date: Mon, 7 Apr 2003 21:10:21 -0400 (EDT) From: "Geoffrey C. Speicher" To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marc Ernst Eddy van Woerkom cc: Poul-Henning Kamp cc: freebsd-hackers@FreeBSD.org Subject: RE: kernel device dependency and sys/conf/files format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2003 00:57:54 -0000 On Mon, 7 Apr 2003, John Baldwin wrote: > > On 05-Apr-2003 Geoffrey C. Speicher wrote: > > I'm revisiting the project to determine device dependency in the kernel, > > and I've run into a situation where net/if.c requires the ether device, > > but no device appears to require net/if.c directly. > > > > sys/conf/files says that net/if.c is "standard", but I have no idea what > > that means in terms of building a kernel. An entry (filename) in that > > file can be listed as standard, mandatory, optional, or count. Mandatory > > and optional seem pretty self-explanatory, but can anyone explain the > > meaning of standard and count? > > > > I assume that net/if.c can be removed from the build or else it would be > > listed as mandatory, but it does appear that an awful lot of things > > implicitly depend on it. > > Eh? I am not aware of any 'mandatory' entries in sys/conf/files*. This > is what I get: > > > grep mandatory /sys/conf/files* > > > > Basically, 'standard' is how you spell 'mandatory' in sys/conf/files*. Now that's interesting, because config(8) handles 'mandatory' entries differently than 'standard' entries, though mostly only so far as syntax is concerned, in that 'mandatory' requires a device name while 'standard' forbids one. Hmm, cvsweb tell me that the 'mandatory' keyword was introduced in revision 1.24 of src/usr.sbin/config/mkmakefile.c in 1997 specifically for device "npx". But then in Jan 2002, the only use of the keyword (for npx) was removed, basically saying that it never should have been listed as mandatory in the first place. But that's another can of worms. I guess what I really care about is whether you can remove a 'standard' thing from a kernel build, and from the looks of it, you can't. So now that I'm beginning to understand how this works, I see that sys/if.c only requires device ether when "options INET" is in the kernel config file. It turns out that this dependency cascades to option "INET6", as well as devices "sl", "ppp", "tun", and "gif" (though mostly because warnings of unused variables are treated as errors in the kernel). (Side note: oddly enough, device "faith" compiles in the absence of INET and INET6.) But the real thing to note here is that a kernel with IP support requires device "ether", though it's perfectly conceivable to have hardware with only a serial ppp interface connected to a network. Whether or not that's a problem that should be addressed, I'll leave up for debate, but it seems that it should be solvable at least in part by introducing "options ETHERNET" for use as a wrapper in sys/net/if.c around arp-related activity, which is really probably what the author meant rather than using "options INET" as the deciding factor for arp existence. Here's another good question: why are there a ton of devices in NOTES that require ether, but ether isn't in NOTES? I think I'm beginning to understand why PHK put this on his junior kernel hacker list. :) Geoff