kernel device dependency and sys/conf/files format

[Geoffrey C. Speicher]

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