> > | > > | 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.
-
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/
This archive was generated by hypermail 2b29 : Tue Jan 07 2003 - 22:00:17 EST