Is there a description or statement that describes the stock kernal in CentOS, and would give all the various modules it is compiled with? As with BSD, I assume there are things in the kernal that are mandatory, and then there are things that are optional or included so as to catch most everything one could have w/r/t hardware. That being the case, as with FreeBSD, removing those unneded modules would work to reduce the size of the kernal. Aside from rebuilding the kernal to have it contain certain objects needed for something to work, and the loading of different modules at runtime, are there any other benefits to building a custom kernal for any particular set of hardware? By leaving the modules not needed, how much, if any, overhead does this contribute to size?
Is this sort of the way things work under Linux, or am I all wet in my thinking?
Sam Drinkard sam@wa4phy.net wrote:
Is there a description or statement that describes the stock kernal in CentOS, and would give all the various
modules
it is compiled with?
The "config" files in the "kernel*.src.rpm" will give you the _exact_ ".config" used when the kernel is built for the specific architecture.
If you want to know what the kernel has been patched with versus the stock, then you can just do a "rpm -qpl kernel*.src.rpm" without even installing it.
As with BSD, I assume there are things in the kernal that
are
mandatory, and then there are things that are optional or included so as to catch most everything one could have
w/r/t
hardware. That being the case, as with FreeBSD, removing those unneded modules would work to reduce the size of the kernal.
It reduces the overall _disk_space_ used by the kernel, yes.
But there isn't much that must be statically built into the kernel itself these days.
Aside from rebuilding the kernal to have it contain certain objects needed for something to work, and the loading of different modules at runtime, are there any other benefits to building a custom kernal for any particular set of
hardware?
For general desktop, workstation, server use? Probably none at all. Boot-time issues are handled by the initrd. And the kernel is overwhelmingly modular. Even the i686 target in kernel 2.6 loads CPU optimizations dynamically.
If you are building an embedded device (assumingly MMU-based), then there are good reasons to build a custom kernel. More than just size, there are some key tweaks to the kernel -- e.g., optimizing the network stack as a bridge/router, instead of a host.
If you start with anything, it's best to start with the .config file that is used to build the production RPM. Those settings have been well-tested by Red Hat (even in Fedora Core).
By leaving the modules not needed, how much, if any,
overhead
does this contribute to size?
The overwhelming size of the kernel today are the modules in /lib/modules/`uname -r`/ -- the optional modules the kernel may or may not load, depending on hardware.
But the kernel program itself ("/boot/vmlinuz" in Fedora-based distros) is not large at all.
Is this sort of the way things work under Linux, or am I all wet in my thinking?
There are still people who refuse to do anything but build a custom kernel.
For myself, I have not built a custom kernel for a desktop, workstation or server in over 5 years -- with rare exceptions. I never do it just for a driver update or anything else that can be done as a module in a fraction of a time.
Especially not for kernel 2.6, which includes all the headers necessary (in /lib/modules/`uname -r`/build/) to build the overwhelming majority of drivers.
Bryan J. Smith wrote:
Sam Drinkard sam@wa4phy.net wrote:
Is there a description or statement that describes the stock kernal in CentOS, and would give all the various modules it is compiled with?
The "config" files in the "kernel*.src.rpm" will give you the _exact_ ".config" used when the kernel is built for the specific architecture.
While /boot/config-`uname -r` will give you the exact .config which has been used for the *running* kernel.
Ralph
Ralph Angenendt ra+centos@br-online.de wrote:
While /boot/config-`uname -r` will give you the exact .config which has been used for the *running* kernel.
Geez, have I been so oblivious that I haven't noticed that file ever before? Wow! BTW, what release did they start doing that?
On Wed, 30 Nov 2005, Bryan J. Smith wrote:
Ralph Angenendt ra+centos@br-online.de wrote:
While /boot/config-`uname -r` will give you the exact .config which has been used for the *running* kernel.
Geez, have I been so oblivious that I haven't noticed that file ever before? Wow! BTW, what release did they start doing that?
It goes back at least as far as RHL 9 (I still have one of those running). I am not sure but I seem to remember it before that but I could be wrong.
Regards,
Tom
Tom Diehl tdiehl@rogueind.com wrote:
It goes back at least as far as RHL 9 (I still have one of those running). I am not sure but I seem to remember it
before
that but I could be wrong.
I want to say it wasn't in RHL7, but I could be wrong. Thanx for correctly my ignorance, regardless of when the change was made.
Bryan J. Smith wrote:
Tom Diehl tdiehl@rogueind.com wrote:
It goes back at least as far as RHL 9 (I still have one of those running). I am not sure but I seem to remember it
before
that but I could be wrong.
I want to say it wasn't in RHL7, but I could be wrong. Thanx for correctly my ignorance, regardless of when the change was made.
Referring to my archives, It was NOT in RH7.3. It IS IN FC1. I skipped RH8 and RH9.
Robert kerplop@sbcglobal.net wrote:
Referring to my archives, It was NOT in RH7.3. It IS IN FC1. I skipped RH8 and RH9.
Regardless, I didn't notice it before, so thanx for correcting my ignorance.
Kernel building actually hasn't changed much from RHL6.1+, as I was building kernels from .src.rpm (SPEC files, patches, etc...) as early as RHL6.2. It really became a necessity in RHL7, especially 7.1+, as the headers and other issues came around.
I guess I just didn't notice the /boot/config-* files in newer releases. Again ... DOH!