[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Given an image, how can show its config?
Keith Owens wrote:
> On Sat, 23 Sep 2000 14:15:44 +0100 (BST),
> James Sutherland <> wrote:
> >How about putting these files in the modules directory? That way, we have
> >a nice consistent location for them.
> Why do you think modutils 2.3.14 added a prune list of files to ignore
> in /lib/modules/`uname -r`? The current (2.3.17) list from modprobe -c is
> # Prune
> prune modules.dep
> prune modules.pcimap
> prune
> prune .config
> prune build
> prune vmlinux
> prune vmlinuz
> prune bzImage
> prune zImage
> The 2.5 Makefiles rewrite will create /lib/modules/`uname -r`, even if
> you do not use modules (Hi, Rusty ;) and install the kernel specific
> output files in it. There will also be enough information saved in
> /lib/modules to allow external compilation of third party software
> without having to guess what the kernel compile options were, this
> includes module symbol version information. This is all covered in
> The Makefile rewrite is definitely a 2.5 project, it is too big a
> change for 2.4. Whether we rename /lib/modules to /lib/kernel has not
> been decided yet. BTW, any discussion about this rewrite should be on
> the linux-kbuild list, not linux-kernel (yet). See 2.4.0-test9-pre6

I'm slowly drifting towards enlightenment on this issue. Let me try to
state this in simple terms I can understand: the tree descending from
the revision name in the modules directory will contain everything
needed to:

- Boot and run a given kernel + modules
- Reconfigure the same kernel, given the original source tree
- Support symbolic crash dumps and debugging

And to satisfy these needs the following will be saved in that tree:

- Kernel image (one or more of vmlinux, vmlinuz, etc.)
- Module tree
- Kernel configuration (.config)
- Module dependencies
- Kernel symbols (

This makes sense to me. This arrangement keeps track of my .config and and gives me a nice mindless 'make install' that does it
all. Gosh, we could even put a README in it. The next obvious thing to
do is move the whole tree to the /boot directory, leaving just a
symbolic link in /lib/modules.

I'll stop promoting the idea of tacking a portion of this tree onto the
bzImage. This can wait, and if I want it, it would be better to tack on
the whole tree anyway, filtered for the parts I don't need. This would
give a nice, linear file that I can just cat onto any boot device or
feed to lilo in the usual way. It also suggests a way of loading
modules using a stub filesystem that knows only about the bzImage. The
bottom line is I can stop panicking about this issue and panic about
something else instead :-)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.080 / U:8.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site