From owner-freebsd-hackers Fri Mar 21 8:48:24 2003 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 F048937B404 for ; Fri, 21 Mar 2003 08:48:22 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C1D43F75 for ; Fri, 21 Mar 2003 08:48:18 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id h2LGlhgO058468; Fri, 21 Mar 2003 19:47:44 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id h2LGlgTP058467; Fri, 21 Mar 2003 19:47:42 +0300 (MSK) (envelope-from yar) Date: Fri, 21 Mar 2003 19:47:42 +0300 From: Yar Tikhiy To: The Anarcat Cc: "Nikolay Y. Orlyuk" , hackers@freebsd.org Subject: Re: Build options for kernel modules Message-ID: <20030321164741.GA57884@comp.chem.msu.su> References: <20030321153217.GA53518@comp.chem.msu.su> <20030321153907.GQ76182@asu.ntu-kpi.kiev.ua> <20030321161658.GA56375@comp.chem.msu.su> <20030321162501.GC1174@lenny.anarcat.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030321162501.GC1174@lenny.anarcat.ath.cx> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote: > On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: > > > > Yeah, it's all right to compile modules w/o the kernel, but that's > > not exactly what I was asking about. My question was whether "option > > FOO" lines from a kernel configuration file could influence modules. > > I'm pretty sure they do. A great example is IPFIREWALL_* options: if > they don't influence the module, I think we have a problem. ;) My testing a yesterday's CURRENT has shown we did have the problem. Everobody is invited to set "options IPFIREWALL_DEFAULT_TO_ACCEPT" and to load the resulting ipfw.ko on a remote machine without human access ;-))) [small print: it's a joke, don't actually do that.] -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message