Messages in this thread | | | From | Marco Colombo <> | Subject | Re: How to check the kernel compile options ? |
| |
On Wed, 6 Feb 2002 Andries.Brouwer@cwi.nl wrote:
> > I would be surprised if there is anyone on this list > > who has not lost at some point either the .config, the > > ksyms, or something similar associated with at least > > one build they've made. > > Sure. And people have lost their root filesystems due to "rm -rf /". > That doesn't mean we build the entire (real) root filesystem into > the kernel. > > -hpa > > Peter, in my eyes this is an unreasonable answer. > > For debugging and other purposes it is good to have some > information. One may wish to know about a certain kernel image > what Linux kernel version that was, with what patches, compiled > with what options, by which compiler. Or one may want to know > such things about the currently running kernel. Even user-space > programs (like mount) may want to know (what NFS version? do we > have CONFIG_JOLIET?).
No, applications already can (should) recover from a "missing feature" error, after executing some syscall. Even if your .config says you've compile the scsi tape driver into the running kernel, it doesn't mean there is a scsi tape attached somewhere. And if your kernel is modular, how can an application tell if some module is avalable? .config may say that feature was compliled as a module, but has no knowledge of the binary module being accessible or not.
> Today we supply a little of this information. > For example, /proc/version supplies information on version > and compiler and date. Why? One might as well keep this compiler > info in a separate file. What a waste of unswappable kernel memory!
You have a point here, IMHO.
$ cat /proc/version Linux version 2.4.9-21 (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 Thu Jan 17 13:35:37 EST 2002
email addresses, compiler versions, distro release strings, build dates, all belongs to the same place of .config. And all are retrievable performing rpm -qi. And overall less useful than .config.
Uh, but wait, that's RH bloat... B-)
> You see - this is not a matter of absolutes. > In the good old days, when an operating system had to fit in 4k > and a device driver in 128 words, putting a 100-char text like > the one found in /proc/version into the system would be ridiculous. > Today nobody worries about a hundred bytes paid for some useful info. > > So, the question is: how useful is the information, and how expensive > is it to store it. Consider the config options. How much space do they > take? Typically 1-5 kB (compressed). If this is stored at the end of > a kernel image file, and not loaded into memory, then the kernel memory > cost is zero. If this is made part of the kernel itself, say accessible > via /proc, then the cost is 1-5 kB.
No, the question is why you need to bury this info into the kernel. The information *is* available, unless you delete it (or forget to save it, or use the wrong tool to install the kernel, and so on).
> So, you should ponder whether it is worthwhile to pay this cost of zero, > and ponder whether it is worthwhile to pay this cost of 5 kB.
To gain what? To recover it if someone deletes /lib/modules/`uname -r`/config.gz (or /boot/config-`uname -r`.gz)?
> Andries
.TM.
- 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/
| |