In some email I received from Jonathan Stone, sie wrote:
> 
> 
> On  Mon, 28 Apr 1997 18:41:41 -0700, Jason Thorpe <thorpej@nas.nasa.gov>
> writes:
> 
> >If you revert it to the old behavior, I will be at LEAST mildly annoyed.
> 
> Well, then, we'll be even;).  Your ``fix'' added a bug to my firewall.

And, I suspect, Jonathan's isn't the only one...especailly given the man page
wasn't updated for "ipf -E" (pedantic, but important point).

> >With the previous behavior, every packet was passed through the
> >filter rule checker even if no rules had been loaded, and the user
> >had no intention of loading them.  That's a _bug_.
> 
> Jason, I don't agree. If the user configured ipfilter into their
> kernel, then passing every packet through the rule-filter engine is
> exactly what the user _asked_ for.  Not passing all packets through
> the rulefilter is a _bug_.  I think that's what Darren is saying, too.  

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 agree with Matt - IPFILTER should be commented out in GENERIC.

> I thought Darren was saying that loading an ipfilter LKM should _also_
> pass all packets through the rule-filter, unless otherwise specified.
> Darren, could you clarify that?

Initially, I didn't allow -D/-E in LMK's becauase they are synonymous
with loading and unloading the module.  I'm not sure with why it was
included, except that I suspect securelevel has something to do with it.

Loading a kernel module implies you want something to be working in your
kernel.  It should (IMHO) load in and start working from then on - the
same as when compiled into the kernel.

What was the namespace collision that you were worried about ?

If you mean "ipfilterattach" (and the pseudo-device ipfilter) then I
think that was put there by design by someone.

Darren