Messages in this thread |  | | | Subject | Re: t: Re: config procfs patch | | Date | Wed, 28 May 1997 18:11:40 -0500 | | From | Evan Jeffrey <> |
| |
>>Sorry if I am being obtuse, but the above paragraph makes little to no sense >>to me. The way I see it, if you system is running, you have a kernel image >>somewhere. While it is possible to delete the image of a running kernel, in > >Thats wrong. > >Boot from CD, boot from Floppy Disk... you cannot force your users >to leave the floppy inserted all the time when they did boot form disk.. > >or maybe they booted from an innaccessible disk via loadlin... > >there is no way to access the bootimage after booting.
OK, I stand corrected. However, I still think that putting it in an extra ELF segment that isn't loaded is the best idea. Think about the uses of the infomation. Basically, the reason for having it in the kernel at all is to allow people who nuked their source tree (or never had one) to figure out what the configuration for it was, either to build a new kernel, make a bug report, or something similar. In those cases it is not unreasonable to ask to have the boot medum preset/mounted to get the info. After all, currently you have to mount the device with your kernel tree to get it. IMO, /proc should be for dynamic sorts of information, not just a storehouse for data that we think users might delete even though they will want it later. If the config needs to be accessable on a regular basis, presumably, people will copy it to a safe location. If userland programs want to read the file to get system information, (another thing which putting it in /proc would encourage) they are broken badly (IMO).
If it is a config option to make a /proc/config file, and people have to conciously say "yes", wouldn't it be easier to just save the file in the first place? The build process should automatically "do the ELF thing" and be done with it.
Finally, it is easier to get the info out of a non-running kernel if the data is in its on segment, rather than buried in with everything else. This is nice if I want to look at a kernel without rebooting.
Just for interest's sake, if someone does put it in the kernel image, perhaps System.map should go in there too, both are useful for people wanting to provide debug reports who have nuked their source trees)
If every "enhancement" for which someone said "then just make it a config option" that I have seen in 6 months of following this list actually went into the kernel, doing a "make config" would take about 17 hours. Flexibility is IMO one of Linux's greatest assets, but let's not go overboard.
=== Evan Jeffrey erjeffre@artsci.wustl.edu
Let us go. Let us leave this festering hell hole. Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Dirk Gently
|  |