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 */
In message <[email protected]> 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.
> 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
In message <[email protected]> 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.
On Sun, 29 Dec 2002, Rusty Russell wrote:
| In message <[email protected]> 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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> > | 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.
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> > | > > | 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.
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