I'm going to put my voice in in favor of Jason here, because I think
these issues should be treated consistently by the kernel
configuration system.  I really have no stake in how IP filtering
works.

>> Well, then, we'll be even;).  Your ``fix'' added a bug to my firewall.
> And, I suspect, Jonathan's isn't the only one

Am I correct that ipfilter support was added after 1.2?  If so, then I
don't think backward compatibility is really an issue.

> I am.  If you have it configred, for your kernel, and you haven't
> disabled it then it should be enabled.  After all, you have already
> asked for it to be included, why disable it by default ?

"I want support for foo in my kernel" and "I want foo turned on" are
two different statements and, by and large, they are treated as
separate statements by the NetBSD kernel.  Why should we violate this
paradigm in the case of IP filtering and nothing else?

(I attribute some weight to the argument, "because that's how other
systems do it," but I don't think this is an area where compatibility
with other systems is a big enough deal to warrant a design
inconsistency.)

> I agree with Matt - IPFILTER should be commented out in GENERIC.

I find it bothersome that we would remove functionality from the
generic kernel because a fully functional kernel doesn't work with our
default system configuration files.

> Loading a kernel module implies you want something to be working in
> your kernel.

Loading a kernel module implies you want support for something in your
kernel.  That's all.  When I load a kernel module for a filesystem, I
don't expect it to be mounted; when I load a kernel module for a
system call, I don't expect it to be executed.  It's true that IP
filtering is a somewhat different breed of fish, since it's a hook
into packet handling, but I still maintain that adding support for a
feature should not substantially change the behavior of the system
until that feature is used.