Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: Given an image, how can show its config? | Date | Mon, 25 Sep 2000 11:03:24 +0200 |
| |
Keith Owens wrote: > > On Sat, 23 Sep 2000 14:15:44 +0100 (BST), > James Sutherland <jas88@cam.ac.uk> 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 System.map > 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 > > ftp://ftp.kernel.org/pub/linux/kernel/projects/kbuild/makefile-wishlist-2.5-4.bz2. > > 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 > MAINTAINERS.
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 (System.map)
This makes sense to me. This arrangement keeps track of my .config and System.map 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 :-)
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |