Subject: Re: Use of opt_ headers
To: Quentin Garnier <>
From: David Laight <>
List: tech-kern
Date: 08/28/2006 11:44:28
On Mon, Aug 28, 2006 at 12:23:49PM +0200, Quentin Garnier wrote:
> On Mon, Aug 28, 2006 at 10:07:28AM +0100, David Laight wrote:
> [...]
> > Code will then have to contain '#if FOO()' which generated a syntax error
> > if opt_foo.h isn't defined.
> > 
> > Any other thoughts/objections before I try to script the required edit?
> > Separating the 'option configured' from the 'option enabled' by having
> > two #defines would make any automated edit completely impossible.
> > 
> > I might also change the defines to be KERNEL_OPT_FOO at the same time.
> What happens to LKMs that use source files from the tree?

Well, at the moment LKMs have a hard time being compatible with anything
that might depend on a kernel option.

I presume they are compiled without -D_KERNEL_OPT ?

Although really they need the set of opt_*.h used to compile the kernel,
(or even there own set in some cases!)
or we need to sort out an real DDI/DKI so that the kernel options are
not as pervasive, and either don't affect any non-driver-specific
header files, or have definitions when _KERNEL_OPT is undefined for
loadable drivers to use.

For the momemt I'd expect header files to re-verify _KERNEL_OPT and/or
for loadable module builds to specify the kernel options for which they
are being built.

In practise there shouldn't be much in generic header files that depends
on kernel options - except major ones like MULTIPROCESSOR.


David Laight: