RE: [PATCH] fix os release detection in module-init-tools-0.9.6

RE: [PATCH] fix os release detection in module-init-tools-0.9.6

[Zhuang, Louis]

> 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?
Second, when module version is back, how can I know what is the magic
version number on the system?

Yours truly,
  - Louis

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Rusty Russell]

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.

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Randy.Dunlap]

On Sun, 29 Dec 2002, Rusty Russell wrote:

| 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.

Right, the .config file is the answer.  And there are at least 2
patch solutions for it, the /proc/config that Rusty mentioned, or
the in-kernel config that Khalid Aziz and others from HP did along
with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.

-- 
~Randy

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Bill Davidsen]

On Sun, 29 Dec 2002, Randy.Dunlap wrote:

> On Sun, 29 Dec 2002, Rusty Russell wrote:

> | 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.
> 
> Right, the .config file is the answer.  And there are at least 2
> patch solutions for it, the /proc/config that Rusty mentioned, or
> the in-kernel config that Khalid Aziz and others from HP did along
> with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.

It would be useful to have a few global options perhaps included in /proc
(or wherever) on all kernels. By global I mean those which affect the
entire kernel, like preempt or smp, rather than driver options. We already
note 'tainted,' so this is not a totally new idea. It would seem that most
of the processor options could fall in this class, MCE, IOAPIC, etc.

If the aim is to speed stability, putting any of the "whole config"
options in and defaulted on might be a step toward that.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[John Bradford]

> > | 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.
> > 
> > Right, the .config file is the answer.  And there are at least 2
> > patch solutions for it, the /proc/config that Rusty mentioned, or
> > the in-kernel config that Khalid Aziz and others from HP did along
> > with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.
> 
> It would be useful to have a few global options perhaps included in /proc
> (or wherever) on all kernels. By global I mean those which affect the
> entire kernel, like preempt or smp, rather than driver options. We already
> note 'tainted,' so this is not a totally new idea. It would seem that most
> of the processor options could fall in this class, MCE, IOAPIC, etc.
> 
> If the aim is to speed stability, putting any of the "whole config"
> options in and defaulted on might be a step toward that.

Having all of the config options in a /proc/config file would be a
great help for people using my new bug database, because it would
allow them to upload the .config for their current kernel even if it
is not one they have compiled themselves.

At the moment, the facility to search for bugs via the config options
that cause them is only useful for people who are compiling their own
kernel.

John.

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Randy.Dunlap]

On Wed, 1 Jan 2003, John Bradford wrote:

| > > | 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.
| > >
| > > Right, the .config file is the answer.  And there are at least 2
| > > patch solutions for it, the /proc/config that Rusty mentioned, or
| > > the in-kernel config that Khalid Aziz and others from HP did along
| > > with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.
| >
| > It would be useful to have a few global options perhaps included in /proc
| > (or wherever) on all kernels. By global I mean those which affect the
| > entire kernel, like preempt or smp, rather than driver options. We already
| > note 'tainted,' so this is not a totally new idea. It would seem that most
| > of the processor options could fall in this class, MCE, IOAPIC, etc.
| >
| > If the aim is to speed stability, putting any of the "whole config"
| > options in and defaulted on might be a step toward that.
|
| Having all of the config options in a /proc/config file would be a
| great help for people using my new bug database, because it would
| allow them to upload the .config for their current kernel even if it
| is not one they have compiled themselves.

It seems that we still differ that putting them in /proc
is required.  I don't see a hard requirement for that as long
as the vmlinu[xz] or bzImage etc. file contains the config
strings, which is what the other mentioned patch does.

They are still affixed to a particular file, and they can be
pulled from it whether it's the running kernel or not.
Putting them in /proc wastes RAM and is undesirable, at least
on small systems and most embedded platforms.
However, that patch does also contain an option for putting
the config entries in /proc.  :)

| At the moment, the facility to search for bugs via the config options
| that cause them is only useful for people who are compiling their own
| kernel.

-- 
~Randy

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Bill Davidsen]

On Wed, 1 Jan 2003, Randy.Dunlap wrote:

> On Wed, 1 Jan 2003, John Bradford wrote:
> 
> | > > | 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.
> | > >
> | > > Right, the .config file is the answer.  And there are at least 2
> | > > patch solutions for it, the /proc/config that Rusty mentioned, or
> | > > the in-kernel config that Khalid Aziz and others from HP did along
> | > > with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.
> | >
> | > It would be useful to have a few global options perhaps included in /proc
> | > (or wherever) on all kernels. By global I mean those which affect the
> | > entire kernel, like preempt or smp, rather than driver options. We already
> | > note 'tainted,' so this is not a totally new idea. It would seem that most
> | > of the processor options could fall in this class, MCE, IOAPIC, etc.
> | >
> | > If the aim is to speed stability, putting any of the "whole config"
> | > options in and defaulted on might be a step toward that.
> |
> | Having all of the config options in a /proc/config file would be a
> | great help for people using my new bug database, because it would
> | allow them to upload the .config for their current kernel even if it
> | is not one they have compiled themselves.
> 
> It seems that we still differ that putting them in /proc
> is required.  I don't see a hard requirement for that as long
> as the vmlinu[xz] or bzImage etc. file contains the config
> strings, which is what the other mentioned patch does.

The problem is that a failing kernel shouldn't be trying to get that info,
and it would be (at least) as valuable as tainted to have a summary line
showing the global options in the oops.

> They are still affixed to a particular file, and they can be
> pulled from it whether it's the running kernel or not.
> Putting them in /proc wastes RAM and is undesirable, at least
> on small systems and most embedded platforms.
So do many other optional things. That's why they're optional. Putting the
whole .config in /proc should be optional, a few global flags like preempt
are probably valuable enough in an oops to justify a few bytes.

> However, that patch does also contain an option for putting
> the config entries in /proc.  :)
> 
> | At the moment, the facility to search for bugs via the config options
> | that cause them is only useful for people who are compiling their own
> | kernel.

That one *would* be solved by a .config added to the vmlinuz file, or by a
config list in /lib/modules/{kernel}, etc.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[John Bradford]

> > | > > | 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.
> > | > >
> > | > > Right, the .config file is the answer.  And there are at least 2
> > | > > patch solutions for it, the /proc/config that Rusty mentioned, or
> > | > > the in-kernel config that Khalid Aziz and others from HP did along
> > | > > with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.
> > | >
> > | > It would be useful to have a few global options perhaps included in /proc
> > | > (or wherever) on all kernels. By global I mean those which affect the
> > | > entire kernel, like preempt or smp, rather than driver options. We already
> > | > note 'tainted,' so this is not a totally new idea. It would seem that most
> > | > of the processor options could fall in this class, MCE, IOAPIC, etc.
> > | >
> > | > If the aim is to speed stability, putting any of the "whole config"
> > | > options in and defaulted on might be a step toward that.
> > |
> > | Having all of the config options in a /proc/config file would be a
> > | great help for people using my new bug database, because it would
> > | allow them to upload the .config for their current kernel even if it
> > | is not one they have compiled themselves.
> > 
> > It seems that we still differ that putting them in /proc
> > is required.  I don't see a hard requirement for that as long
> > as the vmlinu[xz] or bzImage etc. file contains the config
> > strings, which is what the other mentioned patch does.
> 
> The problem is that a failing kernel shouldn't be trying to get that info,
> and it would be (at least) as valuable as tainted to have a summary line
> showing the global options in the oops.

Yes, you're right, I wasn't thinking - people generally aren't going
to be submitting bug reports about the kernel that's actually running,
they'll boot in to another, (stable), one.

> > They are still affixed to a particular file, and they can be
> > pulled from it whether it's the running kernel or not.
> > Putting them in /proc wastes RAM and is undesirable, at least
> > on small systems and most embedded platforms.
> So do many other optional things. That's why they're optional. Putting the
> whole .config in /proc should be optional, a few global flags like preempt
> are probably valuable enough in an oops to justify a few bytes.

The way to do it, then, would be to have a directory with files
created for each enabled option.

I.E. instead of having a file that resembled a .config file somewhere
in /proc, have a directory called config in proc:

# ls /proc/config
CONFIG_X86	CONFIG_MMU		CONFIG_SWAP
CONFIG_UID16	CONFIG_GENERIC_ISA_DMA	CONFIG_EXPERIMENTAL

..etc...

# cat /proc/config/CONFIG_X86
y

That way, on an embedded system you can eliminate some of the entries,
and a check such as

if exist(/proc/CONFIG_X86) echo 'Running on an X86'

will still work, regardless of whether, E.G. CONFIG_PCI_NAMES has been
included, or left out to save memory.

> > | At the moment, the facility to search for bugs via the config options
> > | that cause them is only useful for people who are compiling their own
> > | kernel.
> 
> That one *would* be solved by a .config added to the vmlinuz file, or by a
> config list in /lib/modules/{kernel}, etc.

One solution would be for people to upload their whole kernel, and
have my DB just parse the .config part at the end - a bit wasteful,
but if it makes it easier for people to submit bug reports, then maybe
it's a necessary feature.

John.

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Randy.Dunlap]

On Thu, 2 Jan 2003, Bill Davidsen wrote:

| On Wed, 1 Jan 2003, Randy.Dunlap wrote:
|
| > On Wed, 1 Jan 2003, John Bradford wrote:
| >
| > | > > | 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.
| > | > >
| > | > > Right, the .config file is the answer.  And there are at least 2
| > | > > patch solutions for it, the /proc/config that Rusty mentioned, or
| > | > > the in-kernel config that Khalid Aziz and others from HP did along
| > | > > with me, and it's in 2.4.recent-ac or 2.5.recent-dcl or 2.5.recent-cgl.
| > | >
| > | > It would be useful to have a few global options perhaps included in /proc
| > | > (or wherever) on all kernels. By global I mean those which affect the
| > | > entire kernel, like preempt or smp, rather than driver options. We already
| > | > note 'tainted,' so this is not a totally new idea. It would seem that most
| > | > of the processor options could fall in this class, MCE, IOAPIC, etc.
| > | >
| > | > If the aim is to speed stability, putting any of the "whole config"
| > | > options in and defaulted on might be a step toward that.
| > |
| > | Having all of the config options in a /proc/config file would be a
| > | great help for people using my new bug database, because it would
| > | allow them to upload the .config for their current kernel even if it
| > | is not one they have compiled themselves.
| >
| > It seems that we still differ that putting them in /proc
| > is required.  I don't see a hard requirement for that as long
| > as the vmlinu[xz] or bzImage etc. file contains the config
| > strings, which is what the other mentioned patch does.
|
| The problem is that a failing kernel shouldn't be trying to get that info,
| and it would be (at least) as valuable as tainted to have a summary line
| showing the global options in the oops.

Oh, I see.  You want a few "key" options to be printed during the
oops message, similar to the Tainted flags.  Is that right?

| > They are still affixed to a particular file, and they can be
| > pulled from it whether it's the running kernel or not.
| > Putting them in /proc wastes RAM and is undesirable, at least
| > on small systems and most embedded platforms.
| So do many other optional things. That's why they're optional. Putting the
| whole .config in /proc should be optional, a few global flags like preempt
| are probably valuable enough in an oops to justify a few bytes.
|
| > However, that patch does also contain an option for putting
| > the config entries in /proc.  :)
| >
| > | At the moment, the facility to search for bugs via the config options
| > | that cause them is only useful for people who are compiling their own
| > | kernel.
|
| That one *would* be solved by a .config added to the vmlinuz file, or by a
| config list in /lib/modules/{kernel}, etc.

Sure, and people already have install scripts that copy kernels and config
files to "permanent" locations to do this (latter one).
I know that I've seen someone else mention doing this (maybe akpm) and
my install script does it also.

-- 
~Randy

[PATCH] fix os release detection in module-init-tools-0.9.6

[Zhuang, Louis]

Dear Rusty,
	IMHO, try_old_version can tell kernel release better with this
patch, don't you? ;->
  - Louis

diff -Nur module-init-tools-0.9.6/backwards_compat.c
module-init-tools-0.9.6-lz1/backwards_compat.c
--- module-init-tools-0.9.6/backwards_compat.c	2002-12-21
12:31:11.000000000 +0800
+++ module-init-tools-0.9.6-lz1/backwards_compat.c	2002-12-28
13:29:50.000000000 +0800
@@ -4,6 +4,7 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/utsname.h>
 #include <unistd.h>
 #include <stdlib.h>
 #include <errno.h>
@@ -59,10 +60,14 @@
 static void try_old_version(const char *progname, char *argv[])
 {
 	struct stat buf;
-	/* 2.2 and 2.4 have a syscall.  2.0 doesn't, but does have
-           /proc/ksyms */
+	struct utsname un;
+
+	uname(&un);
+	
+	/* 2.2 and 2.4 have a syscall.  2.0 doesn't, so we compare
+	   release */
 	if (query_module(NULL, 0, NULL, 0, NULL) == 0
-	    || stat("/proc/ksyms", &buf) == 0)
+	    || strncmp("2.0", un.release, 3) == 0)
 		exec_old(progname, argv);
 }
 #else /* CONFIG_NO_BACKWARDS_COMPAT */

Re: [PATCH] fix os release detection in module-init-tools-0.9.6

[Rusty Russell]

In message <957BD1C2BF3CD411B6C500A0C944CA2601AA1377@pdsmsx32.pd.intel.com> you
 write:
> Dear Rusty,
> 	IMHO, try_old_version can tell kernel release better with this
> patch, don't you? ;->
>   - Louis

I prefer, in principle, to test for features, not kernel versions.
What about 2.1, for example?

I've changed the check to sys_create_module(NULL, 0) != -ENOSYS,
instead, which should cover everything.

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.

My plan was to change the format of /proc/modules slightly to make it
extensible (patch on my page), then add the "start of module"
parameter, which should allow ksymoops and oprofile to handle modules
cleanly again (although ksymoops is less urgent since CONFIG_KALLSYMS
does such a nice job for most things).

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