[Tfug] "No modules loaded"
John Gruenenfelder
johng at as.arizona.edu
Sat Apr 11 21:04:02 MST 2009
On Sat, Apr 11, 2009 at 11:22:08AM -0700, John Karns wrote:
>/Ramble
>It's remarkable how much the body of kernel source has grown over the
>past 5 years or so. After many years of compiling it and installing
>it myself, going through the selection of options with the current
>generation of code is to be confronted with such an array of choices
>and that would seem to require an advanced comp sci degree to be able
>to speculate about their purpose .. or at least a good chunk of time
>devoted to researching the terminology.
>
>Although I did go through the process for a 2.6.24 kernel (cheated,
>and did "make oldconfig" using a Ubuntu .config file from a 2.6.22
>kernel on hand - took well over an hour to compile on this 1.8 Ghz,
>non-dual core laptop), I'm not sure that I want to go to the trouble
>(at least not presently) of constructing an initrd image. But from
>taking the time to expand the one from the .22 installed during the
>upgrade, AFAICT I have a feeling it's mostly superfluous, as about the
>only real purpose it seems to serve is to provide the splash screen
>during bootup, as it's devoid of modules!
I think this is why Linux and other kernel hacking old hats have repeated time
and again that the kernel is very much not intended for end-users. I think
people still didn't get the idea which is why they decided to scrap the
"development" odd numbered kernels, perhaps hoping that if users wanted some
semblance of stability, they would have to use distro supplied kernels.
And you're not that far off the mark with the comment about needing a CS
degree to make heads or tails of it. A great many of the options in the
kernel, especially in the networking section are both supplied by and most
commonly used by people doing computer and network research. They aren't
options that a home user or even a server admin would ever remotely need.
I built my own kernels from the 2.0 days through the start of 2.6 as I always
had several patches to apply to add big features. Often these were support
for the XFS filesystem, patches for sensors code, and a few others I can't
recall at the moment. The kernel was growing rapidly at the time and this was
usually the only way to get some features.
When compiling your own kernel a ramdisk rarely makes sense because you can
make sure to only include boot-necesary code in the kernel and can be
reasonably sure it will always fit in boot memory and you'll have a bootable
kernel.
But now, there's little to no point at all and I just use distro kernels
whenever I possibly can. It makes my life easier since somebody else is on
the lookout for the small issues and I can usually count on hearing about the
big ones. And if I need support for something still not in the kernel? The
module system has advanced to the point that nearly everything can be built as
a module after kernel compile time using the kernels headers. This is how I
compile the ATI, Nvidia, and webcam modules.
And for distro kernels, ramdisks are an absolute necessity since they try to
contain modules for everything you might possibly need to boot. You obviously
don't want to include these in the kernel proper since you end up with wasted
memory. Instead, the ramdisk is freed after use and the regular on-disk
modules take over.
Now, of course I'm not telling a bunch of tech saavy users to give up
compiling their own kernels. Even I still find it interesting to look through
the kernel config/help to see what this piece of software is capable of but
which I'm still not taking advantage. But you should give it a second look.
Is it still necessary? There's little to no speed-up to be gained and you'll
still have access to probably >95% of the kernel's features without the hassle
of having to do it yourself.
--
--John Gruenenfelder Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max
More information about the tfug
mailing list