CentOS - Nov 2005 - Installed Kernal (default)

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?


-- 
Snowman

Sam Drinkard <sam at 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                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)