Keith Owens wrote:
>
> On Sat, 23 Sep 2000 14:15:44 +0100 (BST),
> James Sutherland <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
