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

Bill Davidsen (davidsen@tmr.com)
Thu, 2 Jan 2003 07:47:45 -0500 (EST)


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.

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