linux kernal compile guide?

ncage

Golden Member
Jan 14, 2001
1,608
0
71
HI everyone i found a kernal compile guide long time ago but i have no idea where it is now. It went through most of the options in the kernal and gave advice as to what you should answer for each feature. Does anyone know of a guide like this? Sure the kernal is easy to compile but there are so many freakn options sometimes your scratching your head if you should include it or take it out. For example i came to config_posix_mqueue. It pretty much says if you want to run programs that where made for solaris include this. Hmm i dont' think i have any programs based on solaris that i want to use. It says if unsure say yes. So now im scratching my head saying should i include it or not. Sometimes the help file is definitly not enough. THe description for this compile option is not that bad but some of them are. I am trying to optimize my system and shrink the kernal as small as i can. Any help would be appreciated.

thanks,
ncage
 

drag

Elite Member
Jul 4, 2002
8,708
0
0
"If unsure say yes"
"If unsure say no"

I figure that's pretty good advice. I usually follow it.

Personally what I do is copy the configuration file from the kernel I am currently using and use that.

On modern systems you can usually find the configs in your /boot directory.

So at the base of the kernel source tree I go:
cp /boot/config-whatever ./.config
make oldconfig

Take the defaults for any new questions.. Then I go into menuconfig and double check everything and enable/disable the features I am specificl compiling the kernel for.

That way I keep it as close to the vendor's kernel configuration as possible.
 

P0ldy

Senior member
Dec 13, 2004
420
0
0
You really have to know your computer and what you're going to be doing with it if you want to compile the kernel (unless you want to just build *everything* in). Basically, read the help pages... they usually explain what each option is for.
 

ncage

Golden Member
Jan 14, 2001
1,608
0
71
I know my hardware in my machine. I don't have a problem kernel code for my hardware. That is the easiest part. Look at the compile option i noted above. It has nothing to do with hardware. What you don't know if your going to break some software if you don't compile features in.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: ncage
I know my hardware in my machine. I don't have a problem kernel code for my hardware. That is the easiest part. Look at the compile option i noted above. It has nothing to do with hardware. What you don't know if your going to break some software if you don't compile features in.

I don't think there is a real way to know without knowing the kernel and the applications.

Why would you want to compile your own anyhow?
 

sourceninja

Diamond Member
Mar 8, 2005
8,805
65
91
For fun, for profit (example is if your distro didn't backport the nice new wireless and dual core support in 2.6.17) for buggyness (you want to use reiserFS 4). There are a lot of good and not so good reasons to compile your own kernel. I compile my own kernel because genkernel sucks (and you only have two options with gentoo, genkernel and your own kernel).

Tipicaly I just setup all my drivers, processor type, and other features I've learned I needed over the years. If I am unsure I go with the recomended default as its trivial and really fast to recompile your kernel later. Its not horribly complicated to do and you really can't screw anything up (as long as you keep your old kernel in grub for backup). When a new kernel comes along I just copy the .config over and run make oldconfig. Answer the few questions that pop up and I'm finished. After my system is setup for the first time I always use gconfig over menuconfig. And I always install using make && make modules modules_install install. That way it is easy to debug any problems and it puts everything in /boot for me with nice symlinks so that in grub I have vmlinuz symlinked to the current kernel and vmlinuz.old symlinked for the previous kernel.

The one thing I like about this method is how simple everything is. Normally it is just as trival to build and install a new kernel as it is to just do apt-get install a new kernel. On distro's that supply their own kernels I usually dont compile my own kernel. My exception was with ubuntu 6.06. I compiled my own kernel because there was no k8 32bit kernel and I find ubuntu 64bit very lacking compared to gentoo (although its getting much much better). I dont know if the k8 kernel makes a difference, but it was trivial to and in the least saved me a meg of ram LOL.

Size wise I wouldn't worry too much about your kernel. Just compile suspect things as modules and they wont be loaded into memory. Most options dont increase kernel size that much anyways. Hell my entire boot partition is only 38megs.
 

cleverhandle

Diamond Member
Dec 17, 2001
3,566
3
81
Try things out and see if something breaks. That's what I do at least. Once you've basically got a config file for a given machine you can pretty much just recycle it until a new major revision.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
I figure that's pretty good advice. I usually follow it.

I don't know if I'd trust that, for example CONFIG_LSF says "If unsure, say Y" but how many people are likely to have files >2TB in size? And you have to go in and enabled CONFIG_EMBEDDED (which doesn't really mean embedded any more) if you want the full 1G lowmem stuff to be usable, which most people with 1G of memory probably want.

Sure the kernal is easy to compile but there are so many freakn options sometimes your scratching your head if you should include it or take it out.

I think that's the point, if you don't know what most of the options are for you shouldn't be compiling your own kernel.

I am trying to optimize my system and shrink the kernal as small as i can.

That's pretty much pointless. All modern distros make everything possible a module so the only thing wasted is a bit of disk space. And my /lib/modules/<kernel-version> directory is only ~40M so it's not even a lot of space.
 

ncage

Golden Member
Jan 14, 2001
1,608
0
71
THanks guys. I guess its my misunderstanding of linux. I thought one of the main optimizing things you could do was try to compile less things in the kernel. I wasn't really looking to shave disk space because i have enough hard disk space but i was looking to save memory. I thought shrinking your kernel would have a big effect on memory usage. I also thought it would be more effecient. I guess it was my misunderstanding
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
I thought one of the main optimizing things you could do was try to compile less things in the kernel. I wasn't really looking to shave disk space because i have enough hard disk space but i was looking to save memory. I thought shrinking your kernel would have a big effect on memory usage. I also thought it would be more effecient. I guess it was my misunderstanding

The kernel itself only uses a few megs at most, there's not much more you can trim. And if something is built as a module it doesn't use any resources unless it's loaded.