From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 16:45:18 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FA64F22 for ; Mon, 12 Jan 2015 16:45:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7892875B for ; Mon, 12 Jan 2015 16:45:18 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6BE67B915; Mon, 12 Jan 2015 11:45:17 -0500 (EST) Message-ID: <54B3FA1D.6020605@FreeBSD.org> Date: Mon, 12 Jan 2015 11:45:17 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Robert Bonomi , freebsd-hackers@freebsd.org Subject: Re: passing 'config' file data to a kernel loadable module ?? References: <201412302113.sBULDhan082070@host203.r-bonomi.com> In-Reply-To: <201412302113.sBULDhan082070@host203.r-bonomi.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 11:45:17 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:45:18 -0000 On 12/30/14 4:13 PM, Robert Bonomi wrote: > > I'm hacking on an existing screen-saver module, and would like to set options > in the config file that are passed to the compiler when the module is built. > > I can't find a decent description of the gory details of HOW 'config' works. > Chapter 2 of the SMM, "Building 4.4BSD Kernels with Config" has falsehoods -- > to wit: the example on page 10, under the 'options' keyword, given as > 'options -DFUNNY,-DHAHA' > causes 'config' to abort with a fatal error. > Apparently an 'option' must be defined 'somewhere else', before config > recognizes it. Yes, in sys/conf/options*. > I've got an 'ugly' method -- "makeoptions CONF_CLFAGS+=-D{{NAME}}" -- that > works for compiling the '.o' that gets linked into the kernel executable, > BUT that make variable is not passed to the (separate!!) compile stage for > building a.ko module. Yes, the source-code is compiled _twice_, with the > resulting .o file in two separate locations, and the options passed to the > compiler are *NOT* identical in both instances -- they're 'close', but not > 'exactly the same'. Is there a good reason why they're different? You can use DEBUG with makeoptions as a similar hack. I think that might also work for modules? > Is there an 'approved' way for getting a supplemental 'definition' from the > kernel config file passed to the compile of a loadable module? > > Is there a 'less ugly' way than what I described above, to get such a > definition passed to compilation of a module that will be linked into the > kernel? > > Ideally, is there a single means/method that will accomplish both tasks? > > Wish-list: something that does _not_ require modifying other files in the > 'magic data' that config uses? That is not currently doable. :( > Peripherally related thereunto, is there a cookbook or other example of > making a 'port' for a kernel module, and what all needs to be in it? Do you need to have these settings be compile options vs loader tunables / sysctls? The latter are preferred if at all possible. -- John Baldwin