From owner-freebsd-current  Thu Jun 13 17:03:58 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA13680
          for current-outgoing; Thu, 13 Jun 1996 17:03:58 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA13648;
          Thu, 13 Jun 1996 17:03:48 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id JAA32106; Fri, 14 Jun 1996 09:56:47 +1000
Date: Fri, 14 Jun 1996 09:56:47 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199606132356.JAA32106@godzilla.zeta.org.au>
To: gpalmer@FreeBSD.org, roberto@keltia.freenix.fr
Subject: Re: #include opt_ipfw.h problem for lkm
Cc: freebsd-current@FreeBSD.org
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>> sys/netinet/ip_fw.c includes  "opt_ipfw.h" when compiling the kernel (which
>> is fine) but includes it also when compiling as lkm (which is bad). 

Including it conditionally is the wrong fix.  lkms must not depend on any
options, since their behaviour must be the same as the statically configured
versions.  I think the conditional include doesn't do much damage because
option IPFIREWALL isn't used.  Only the option IPFIREWALL_VERBOSE is used.
Other bugs: option IPFIREWALL_VERBOSE_LIMIT isn't in the options file, and
lkm ipfw and option file opt_ipfw.h have hard to remember names - `ip' is
followed by `_' in all other ip file names.

There is a potentially much more serious problem in the use of the option
IPFIREWALL in ip_input.c.  I think this isn't actually a problem, because
the option is only used to control the initialization of ip_fw, and this
initialization gets done in another way if ip_^Hfw is an lkm.  Why isn't
PSEUDO_SET() used to do the initialization transparently like it is for
other lkm's?  I guess there are ordering problems.

Bruce