public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Fasheh <mark.fasheh@oracle.com>
To: Thomas Schlichter <schlicht@uni-mannheim.de>,
	"Randy.Dunlap" <rddunlap@osdl.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: no version magic, tainting kernel.
Date: Thu, 23 Jan 2003 11:35:40 -0800	[thread overview]
Message-ID: <20030123193540.GD13137@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20030123182236.GA14184@mars.ravnborg.org>

Can't the stuff in init/vermagic.c be moved into a header file? Maybe
vermagic.h? Most of the code can be cut 'n pasted right out of vermagic.c
and the bit that defines "const char vermagic[]..." could be placed inside a
macro which modules would then stick in the bottom of one of their c files.
This is what I'm getting at (warning I haven't checked this code or even
tried to clean it up):

in vermagic.h:
#include <linux/version.h>
#include <linux/module.h>

/* Simply sanity version stamp for modules. */
#ifdef CONFIG_SMP
#define MODULE_VERMAGIC_SMP "SMP "
#else
#define MODULE_VERMAGIC_SMP ""
#endif
#ifdef CONFIG_PREEMPT
#define MODULE_VERMAGIC_PREEMPT "preempt "
#else
#define MODULE_VERMAGIC_PREEMPT ""
#endif
#ifndef MODULE_ARCH_VERMAGIC
#define MODULE_ARCH_VERMAGIC ""
#endif

#define KERNEL_VERSIONMAGIC const char vermagic[]			\
__attribute__((section("__vermagic"))) =				\
       UTS_RELEASE " "							\
       MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT MODULE_ARCH_VERMAGIC	\
       "gcc-" __stringify(__GNUC__) "." __stringify(__GNUC_MINOR__)


in my_external_module.c, and init/vermagic.c I'd just do:
#include <linux/vermagic.h>
KERNEL_VERSIONMAGIC();

and be done with it.

Modules that ship with the kernel wouldn't have to change a thing (and still
be linked against vermagic.c, and it'd only add two lines of code to
everyones externally shipped modules. I don't really think that this would be
"doing too much" for those whose modules are included in Linus's kernel, and
it wouldn't require people to keep entire source tree's around to compile a
module or two...
Am I totally missing something here or wouldn't this solve our problem?
Someone please correct me if I'm wrong :)
	--Mark

On Thu, Jan 23, 2003 at 07:22:36PM +0100, Sam Ravnborg wrote:
> As it is today the only sane way is to have the full kernel src available.
> It should be possible to minimize that - but I do not feel tempted to
> do so.
> 
> We want to do too much to rely on whatever makefile people write for
> their module.
> 
> 	Sam
> -
> 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/

--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh@oracle.com

  reply	other threads:[~2003-01-23 19:26 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-23 13:59 no version magic, tainting kernel Thomas Schlichter
2003-01-23 16:29 ` Randy.Dunlap
2003-01-23 16:52 ` Sam Ravnborg
2003-01-23 17:32   ` Thomas Schlichter
2003-01-23 18:22     ` Sam Ravnborg
2003-01-23 19:35       ` Mark Fasheh [this message]
2003-01-26 13:29         ` Christian Zander
2003-01-26 13:33           ` Keith Owens
2003-01-26 18:02             ` Kai Germaschewski
2003-01-26 17:51           ` Kai Germaschewski
2003-01-26 21:57             ` Christian Zander
2003-01-26 21:46               ` Kai Germaschewski
2003-01-26 23:12                 ` Christian Zander
2003-01-26 22:55                   ` David Woodhouse
2003-01-27  0:07                     ` Christian Zander
2003-01-26 23:16                       ` David Woodhouse
2003-01-27  0:24                         ` Christian Zander
2003-01-27 16:25                         ` Kai Germaschewski
2003-01-27 16:29                           ` David Woodhouse
2003-01-27 16:39                             ` Kai Germaschewski
2003-01-27  6:17                 ` Petr Vandrovec
2003-01-27  9:02                   ` David Woodhouse
2003-01-27  9:24                     ` Petr Vandrovec
2003-01-27 17:59                 ` Joel Becker
2003-01-27 18:31                   ` Kai Germaschewski
2003-01-27 22:15                     ` Joel Becker
2003-01-27 23:08                       ` Kai Germaschewski
2003-01-27 23:37                         ` Joel Becker
2003-01-28 15:43                       ` David Woodhouse
2003-01-28 17:03                         ` Joel Becker
2003-01-26 22:23               ` Christian Zander
2003-01-26 17:43         ` Kai Germaschewski
2003-01-26 22:08           ` Christian Zander
2003-01-26 21:29             ` Sam Ravnborg
2003-01-26 23:03               ` Christian Zander
2003-01-26 21:40             ` David Woodhouse
2003-01-26 23:28               ` Christian Zander
2003-01-26 22:46                 ` David Woodhouse
2003-01-26 23:56                   ` Christian Zander
2003-01-26 23:04                     ` David Woodhouse
2003-01-28  1:58         ` Rusty Russell
2003-01-28 19:10           ` Mark Fasheh
2003-01-28 19:17             ` Kai Germaschewski
2003-01-27 18:52 ` Jerry Cooperstein
2003-01-27 19:12   ` Sam Ravnborg
2003-01-27 19:35     ` Jerry Cooperstein
2003-01-27 19:54   ` Gerd Knorr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030123193540.GD13137@ca-server1.us.oracle.com \
    --to=mark.fasheh@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sam@ravnborg.org \
    --cc=schlicht@uni-mannheim.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox