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/