Quote:
Originally Posted by bamunds
Thank you again bassmadrigal. However, if I do a diff on the two (huge and generic) of both System.map and config, clearly there are significant differences. The huge kernel config is loading everything, while generic config loads many items as modules. Also the System.map keys are significantly different. So I think it makes more sense to use the proper symlinks for both, since I don't know what calls are made to them when booting or when building other packages. For example if I were to build a new kernel locally then I normally will use a config and I'd have to remember to cat the /boot/config-generic-4.4.88 to .config of the new kernel source build location and I'd probably forget. But this is what Linux lessons are all about. In fact your comment made me go look up tldp.org the standard Linux file hierarchy and that could put us in an old thread about Slackbuilds and what directory they should be placing files in for non-default packages of the distribution. Cheers.
|
Of course they're different. They are for two different kernels. As I said before, the System.map file is only used in debugging kernels, which if you're not developing the kernel, it's pretty unlikely that you'll be debugging it. When I build kernels, I don't even bother to move it out of the build directory.
The config is only there for reference. As far as I know, it isn't used for anything by the system. Any program that would want to use the config of the current kernel would use /proc/config.gz as that is the config of the currently running kernel, regardless of what symlinks are used. It is generated on boot by whatever kernel was selected to boot the system. I personally think if you're going to be building a kernel, you'd want to ensure you're getting the right config and not relying that the config symlink is pointing to the file you want.
There's no reason you can't update the symlinks for these files, I was just providing reasons why you don't *need* to.
