[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-package??

Randy Patterson wrote:
My intention at this point is to make a detailed list of the components on a particular system so I can remove everything that is not needed. These would be older systems that will never be upgraded or need new hardware so the kernel don't need a lot of options concerning hardware. For example, I have used ext3 on the drives and they don't need to access anything else and will remove all support for ext2, ext4, NTFS and everything else. I intend to compile everything into the kernel without using modules. It's my understanding from what I have read that this will result in a leaner and some what faster kernel for that system. Is that a reasonable assumption and approach?

What is "reasonable" is a matter of opinion. Even though I carried out the massive research project you are describing above, and determined the exact set of configuration options needed to compile a custom kernel which exactly fits my hardware (and _only_ my hardware), I would not recommend anyone else to do so unless they had some specific need or purpose. My purpose has been to learn how Debian works "under the hood," with the intent of being able to contribute useful work later -- in the form of fixing bugs, writing and packaging my own software, and (possibly) becoming a Debian developer.

Leaner? My own experience is that my kernel binaries are _larger_ than a Debian kitchen-sink kernel, while the disk space taken up for the initial ramdisk (initrd) and loadable modules in /lib/modules goes away almost entirely:

# ls -lA /boot | cut -f5- -d' '
7653318 2009-04-20 07:43 initrd.img-2.6.28-1-amd64
2041664 2009-02-18 13:02 vmlinuz-2.6.28-1-amd64
2921024 2009-03-21 12:57 vmlinuz-2.6.28-2s13145.090321.desktop.uvesafb

# du -s -b /lib/modules/*
210911107	/lib/modules/2.6.28-1-amd64
15089013	/lib/modules/2.6.28-2s13145.090321.desktop.uvesafb

The 15 MB of modules in my current custom kernel's /lib/modules path are mostly unnecessary, and could easily be reduced below 2 MB (maybe even
1 MB).

Faster? I promise that you would not notice the speedup. Conceivably your kernel will boot slightly faster without having to carry out the hardware detection for the 99% of modules that have no relevance for your particular system, but you would have great difficulty measuring the alleged time savings accurately. (There are great opportunities for decreasing the time needed to boot a Debian system, but these have to do with customizing the initialization scripts, not with replacing the kitchen-sink kernel with a custom kernel.)

As far as being in a hurry to leave out unnecessary things like ext2, ext4, and NTFS... I would ask you to reconsider. What happens if you meet other Linux users in your area, and they want to give you some files off of their USB flash drive formatted in ext2 or ext4? Or what happens if some Windows user you meet has some files on their external hard drive... formatted in NTFS? Now your really great idea about compiling your own kernel is really going to make you look smart to those folks, right? Your choices at that point will be to recompile your custom kernel, or boot to a Debian kitchen-sink kernel. (Which just raises the question of why you weren't using the Debian kernel in the first place.)

I'm not trying to discourage you from building your own kernel. I'm trying to offer information that I think you should consider, and I'm offering the advice that you shouldn't bother building your own kernel unless you have some really good reason. (Really good reasons might include a burning desire to simply know how, or to be able to say you did it, but if one of those is you only reason then I think you will regret it by about halfway through the process.)

The Debian kernel team works really hard to make sure that the kernels work, and they do a good job. In the end, I was able to customize my kernel configuration to the point that I can compile a kernel in about 6 minutes on my desktop machine... which is (at least) 6 minutes longer than it would take me to install a Debian kernel. ;) If I hadn't had problems with ALSA support with this machine when I first put it together, I probably would not have bothered to learn to compile my own kernels. The amount of time in invested in learning how to do it now causes me to want to keep doing it, so I don't have the feeling that I wasted those dozens of hours -- and so I am condemned to the punishment of Sisyphus.

The whole subject of initrds scripts is something I will need to study up on. But are you saying that if I don't use modules that I don't need to worry about needing these scripts?

When you boot a kernel, then any feature required by your system to be able to boot will have to be available before your hard disks are mounted. There are two ways to accomplish this:

1. Build the features directly into the kernel binary, instead of building them as loadable modules.

2. Build the features as loadable modules, and then create an initrd which contains the required modules so that the kernel can use them at boot.

Folks who build their own kernels usually look at those choices, and quickly decide not to use an initrd at all. The reason that Linux distributions provide kernels with initrd's is because they want their kernel to run on _everyone's_ hardware, so they turn on almost every conceivable kernel option as a loadable module, then create an initrd containing the modules that might be necessary at boot time.

In my own custom kernel's /lib/modules directory I have about 15 MB of modules -- mostly unnecessary (but you never know). None of these modules are necessary for my system to boot, so I don't need to create an initrd.

Dave W.

Reply to: