Unconditional include of <linux/module.h> in aic7xxx driver

Unconditional include of <linux/module.h> in aic7xxx driver

[Justin T. Gibbs]

Can anyone comment on why the include of <linux/module.h> is now
unconditional in the aic7xxx driver?  Assuming MODULE_LICENSE is
properly qualified by an #ifdef MODULE, the driver appears to compile
and function correctly without this include.  Are MODULE attributes
(MODULE_VERSION/AUTHOR/DESCRIPTION/etc.) now supposed to be included in
static configurations?

Thanks,
Justin

Re: Unconditional include of <linux/module.h> in aic7xxx driver

[Alan Cox]

> unconditional in the aic7xxx driver?  Assuming MODULE_LICENSE is
> properly qualified by an #ifdef MODULE, the driver appears to compile
> and function correctly without this include.  Are MODULE attributes
> (MODULE_VERSION/AUTHOR/DESCRIPTION/etc.) now supposed to be included in
> static configurations?

It's always been meant to work always included. For non modules it defines
the right do nothing handlers to avoid you having to get ifdefs into the
kernel code

Re: Unconditional include of <linux/module.h> in aic7xxx driver

[Justin T. Gibbs]

>> unconditional in the aic7xxx driver?  Assuming MODULE_LICENSE is
>> properly qualified by an #ifdef MODULE, the driver appears to compile
>> and function correctly without this include.  Are MODULE attributes
>> (MODULE_VERSION/AUTHOR/DESCRIPTION/etc.) now supposed to be included in
>> static configurations?
>
>It's always been meant to work always included. For non modules it defines
>the right do nothing handlers to avoid you having to get ifdefs into the
>kernel code

So, in theory I could nuke many of the remaining "#ifdef MODULE"'s?
This wasn't done in the aic7xxx driver for 2.4.12.  My only concern with
doing this is having the driver still work on older kernel versions.

--
Justin

Re: Unconditional include of <linux/module.h> in aic7xxx driver

[Jeff Garzik]

On Thu, 11 Oct 2001, Justin T. Gibbs wrote:
> So, in theory I could nuke many of the remaining "#ifdef MODULE"'s?

yes.  most if not all.


> This wasn't done in the aic7xxx driver for 2.4.12.  My only concern with
> doing this is having the driver still work on older kernel versions.

Define "older" :)  Even 2.2 kernels have worked this way for a while, so
it really depends on how far you want to go back.  I think this policy
started in late 2.1.xx days IIRC.

Also, WRT older kernel compatibility, look at drivers/net/acenic.c or
the kcompat24 toolkit.  These, and other code, illustrate how to be
compatible with older kernels without loading the source code down with
ifdefs.  The basic idea is to provide a 2.4-like API on older kernels,
using macros and inline functions hidden in a compatibility header.

	Jeff

Re: Unconditional include of <linux/module.h> in aic7xxx driver

[Jeff Garzik]

On Thu, 11 Oct 2001, Justin T. Gibbs wrote:
> Can anyone comment on why the include of <linux/module.h> is now
> unconditional in the aic7xxx driver?  Assuming MODULE_LICENSE is
> properly qualified by an #ifdef MODULE, the driver appears to compile
> and function correctly without this include.  Are MODULE attributes
> (MODULE_VERSION/AUTHOR/DESCRIPTION/etc.) now supposed to be included in
> static configurations?

linux/module.h has been set up, for a long while now, to support
building statically into the kernel as well as building as a module.

Linux kernel rule #812: ifdefs are ugly.  Strive to make your code
ifdef free by creating includes/defines/inline functions that exist
even when your selected ifdef is undefined.  module.h follows that
rule.

Similarly you can include linux/pci.h even if !CONFIG_PCI.

	Jeff

Re: Unconditional include of <linux/module.h> in aic7xxx driver

[Keith Owens]

On Thu, 11 Oct 2001 13:40:08 -0600, 
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>Can anyone comment on why the include of <linux/module.h> is now
>unconditional in the aic7xxx driver?  Assuming MODULE_LICENSE is
>properly qualified by an #ifdef MODULE, the driver appears to compile
>and function correctly without this include.  Are MODULE attributes
>(MODULE_VERSION/AUTHOR/DESCRIPTION/etc.) now supposed to be included in
>static configurations?

Absolutely.  module.h detects how the code is being compiled and most
of the macros become noops.  In 2.5 MODULE_PARM will have meaning even
for code built into the kernel, so we get a consistent method of
setting parameters without adding boot line parsing code to every
object.

Always include module.h, never condition MODULE_xxx on CONFIG_MODULES,
init and exit functions should be defined as __init and __exit and
referenced via module_init() and module_exit().  init.h and module.h
will do whatever is necessary, depending on how the code is compiled.