Date: Mon, 12 Jan 2015 11:45:17 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Robert Bonomi <bonomi@mail.r-bonomi.com>, freebsd-hackers@freebsd.org Subject: Re: passing 'config' file data to a kernel loadable module ?? Message-ID: <54B3FA1D.6020605@FreeBSD.org> In-Reply-To: <201412302113.sBULDhan082070@host203.r-bonomi.com> References: <201412302113.sBULDhan082070@host203.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <wry grin>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54B3FA1D.6020605>