Re: unneeded #include <version.h> in many places ?

From: Adrian Bunk (bunk_at_fs.tum.de)
Date: 09/07/04

  • Next message: Sam Ravnborg: "Re: 2.6.9-rc1-mm4"
    Date:	Tue, 7 Sep 2004 21:32:29 +0200
    To: Krzysztof Halasa <khc@pm.waw.pl>
    
    

    On Tue, Sep 07, 2004 at 06:17:53PM +0200, Krzysztof Halasa wrote:

    > Hi,

    Hi Krzysztof,

    > I noticed some kernel .c files #include <version.h> which typically
    > contains something like:
    >
    > #define UTS_RELEASE "2.6.9-rc1"
    > #define LINUX_VERSION_CODE 132617
    > #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
    >
    > However, those files don't reference the macros.
    >
    > The question is: are these includes completely unneeded, so I can
    > remove them, or do they serve some special purpose?

    they don't serve any special purpose.

    But please doublecheck that they are really not needed.

    > Another one: there are drivers using constructs like:
    >
    > #if LINUX_VERSION_CODE > 0x20115
    > ...
    > #endif
    >
    > I understand they can be somehow useful for authors supporting many
    > kernel versions with a single set of files, however the gain isn't
    > clear to me. Should such conditional code be a) removed, b) left
    > in place, c) dealt with each case individually?

    c)

    Many driver authors share their code this way between different major
    kernel versions, which makes it easier for them to maintain their code.

    #ifdef's for kernel 2.4 are often still actively maitained.

    #ifdef's for kernel 2.2 are only very rarely actively maitained.

    #ifdef's for kernel 2.0 (as in your example) are most likely completely
    obsolete.

    > Krzysztof Halasa

    cu
    Adrian

    -- 
           "Is there not promise of rain?" Ling Tan asked suddenly out
            of the darkness. There had been need of rain for many days.
           "Only a promise," Lao Er said.
                                           Pearl S. Buck - Dragon Seed
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Sam Ravnborg: "Re: 2.6.9-rc1-mm4"

    Relevant Pages

    • Re: Bloat report 2.6.3 -> 2.6.4
      ... For the average computer you can buy at your supermarket today it isn't ... People who need to care about the size of the kernel use hand-tuned ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
      ... Kernel SHALL be configuralble with compiler size options, ... "specification" didn't send a patch - the trivial patch was sent by ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Weirdness with suspending jobs in 2.6.9-rc3
      ... >> It doesn't depend on which version I'm compiling, ... >> kernel I'm actually running. ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2
      ... > It's a generic mechanism for userspace driven configuration of kernel ... > subsystems/projects could use it too, ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6 patch] add a config option for -Os compilation
      ... kernel with some supported compilers) ... there might be fast path code somewhere in the kernel that becomes ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)