public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Zhuang, Louis" <louis.zhuang@intel.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Subject: Re: [PATCH] fix os release detection in module-init-tools-0.9.6
Date: Sun, 29 Dec 2002 16:54:58 +1100	[thread overview]
Message-ID: <20021229062833.1598F2C085@lists.samba.org> (raw)
In-Reply-To: Your message of "Sat, 28 Dec 2002 18:38:54 +0800." <957BD1C2BF3CD411B6C500A0C944CA2601AA1378@pdsmsx32.pd.intel.com>

In message <957BD1C2BF3CD411B6C500A0C944CA2601AA1378@pdsmsx32.pd.intel.com> you
 write:
> > Now, why do you want /proc/ksyms exactly?  I'm not hugely opposed to
> > it, but it's rarely what people actually want, since it contains only
> > exported symbols.
> The two things make me want ksyms... ;-)

> First, if I'm a stranger to a system, how can I know if a feature
> (preemptive, for example) is on/off on that?

Um, you read the .config, which hopefully is stored somewhere.
(Although you could resurrect the /proc/config patch which goes around
every so often).  There are many things you can't tell by reading
/proc/ksyms.

> Second, when module version is back, how can I know what is the magic
> version number on the system?

Well, the new version system is a little different.  (I've been
distracted by other things, but un-bitrotting that patch is on my TODO
list).  The idea is that modules have a ".versions" section, which
contains the versions of all the symbols it exports and requires.
When the module is loaded into a kernel with version support, the
version of each symbol is compared: if it's different, the module
can't be loaded.  If it's missing (or the entire section is missing),
the module can be loaded, but taints the kernel.

This allows versioned modules to be loaded into an unversioned kernel
and vice versa, which might be useful.  modprobe just needs a
--strip-version option to rename the .versions section (or remove it,
or whatever), and the picture is complete.

Hope that clarifies,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

  reply	other threads:[~2002-12-29  6:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-28 10:38 [PATCH] fix os release detection in module-init-tools-0.9.6 Zhuang, Louis
2002-12-29  5:54 ` Rusty Russell [this message]
2002-12-29 18:33   ` Randy.Dunlap
2003-01-01 15:51     ` Bill Davidsen
2003-01-01 16:23       ` John Bradford
2003-01-01 18:53         ` Randy.Dunlap
2003-01-02 12:47           ` Bill Davidsen
2003-01-02 13:07             ` John Bradford
2003-01-02 16:22             ` Randy.Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2002-12-28  5:49 Zhuang, Louis
2002-12-28  6:12 ` Rusty Russell

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=20021229062833.1598F2C085@lists.samba.org \
    --to=rusty@rustcorp.com.au \
    --cc=kai@tp1.ruhr-uni-bochum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=louis.zhuang@intel.com \
    /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