> On Sat, 9 Feb 2002, Bill Davidsen wrote:
> | On Wed, 6 Feb 2002, Randy.Dunlap wrote:
> | > I still prefer your suggestion to append it to the kernel image
> | > as __initdata so that it's discarded from memory but can be
> | > read with some tool(s).
> | The problem is that it make the kernel image larger, which lives in /boot
> | on many systems. Putting it in a module directory, even if not a module,
> | would be a better place for creative boot methods, of which there are
> | many.
> Yes, it can add a few KB to a kernel image.
> Some people could think that it's worth it...especially
> if it's a build option.
The capability is definitely desirable, I think it's just implementation
> I prefer this to using /proc/config.gz (which SuSE currently does),
> since the config data won't be in permanent memory, and it's
> attached to a kernel image on disk -- the kernel doesn't have to
> be loaded in memory to view it. (or maybe there's a way to
> view config.gz in a SuSE kernel image ?)
> I don't see how making it a binary module (living in
> /lib/modules/version/kernel/configs.o e.g.) has any advantages
> over kbuild (?) just copying the .config file to
> /lib/modules/2.5.4/.config .
There are already uncompressed pure text files in the modules directory,
such as modules.dep. Adding one more is probably not a space issue on most
systems, while kernel size may be, since it has to be present at boot.
I don't have any issue with allowing a symbolic link in /proc down to the
config, if people want it there. I always Slink the /lib/modules/xxx dir
to /boot/Modules and the current symbols to /boot/System.map as well.
Links in known places are good.
-- bill davidsen <email@example.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 firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/