hello. i want to upgrade my kernel to latest stable 2.6.17.6, and been wondering for some time now about some things. Till now i've always selected at least 95% of the options as built-in and those that i wasn't sure about i left them out. So my main concern is... is it better as built-in or as modules ? If i select an option which i'm not sure of will it break my system ? And if it doesn't break it , does it slow down my sys ? Or if i select an option as module and it's not used by anything, does it still slow my system at boot time or/and runtime ?

Modules don't use any memory unless they are actually loaded. I tend to compile everything that isn't actually need to boot (file system, etc...) as modules.

Compiling everything into the kernel increases the size of the kernel causing it to use more memory and slowing it down a bit.

Just be sure to compile in the things absolutely needed to boot the system. Your filesystems and such should definately be compiled in unless you want to use an initrd.

You would expect that a compiled in function would use less memory than as a module as the "hooks" are simplified. If you are running a filesystem module it will be using memory all the time whichever method. The saving for modules comes when you don't have that hardware on a particular pc.
I use the very basic 2.6 kernels in testing and have learnt the hard way what happens with a typo in the mkinitrd command. Compiling in is safer.

I use these rules.

1. Compile IN the the modules that you need to boot. These are IDE Chipset support, Filesystem support, and anything else you need.
2. Compile IN any other IDE chipset that you think you may use in the future.(Just in case you ever buy a new motherboard, there is literally no performance decrease from building in ALL the chipsets)
3. Compile as MODULES other hardware that you ALWAYS have in your PC(Sound card, USB support, etc.
4. Compile as modules any other hardware that you _think_ you _may_ install one day in the future, becuase having to do a kernel recompile whenever you install new hardware is not a good thing(Not to mention the subsequent rebuild of Nvidia/kqemu/wireless chips/etc.

You have nothing to lose but hard drive space compiling more modules than you need, and chances are you have at least a 10GB machine, and if you do you definitely can afford the 40k that the average module takes up.

Also, kernel size doesn't matter in speed anymore, small is not faster unless you are on a very early 1990s machine.

Wasn't there a problem with alsa recently, that it worked as a module but failed compiled in?

I would always make soundcards modules, simply because it's easy to switch soundcards, and you never know.

Permanent hardware like IDE chipsets should be built in, but hardware that you can/plan to/_might_ switch out should be modules, such as soundcards.

*liquidtenmilion*
i wonder why you would recompile a kernel ?
If one of the standard kernels can boot on your system, there is no need to
recompile, as all of your rules are followed there.

*sl4ckw4re*
when you recompile a kernel, only compile in the support *your machine* needs
at boot time. all stuff that's not needed makes the kernel larger and slows
down the boot process. Besides the things mentioned earlier ( filesystem, chipset-support, IDE/SCSI/SATA )pick the VESA framebuffer-support, to prevent
the "black screen" at boot. ( ...and no other framebuffer support ).

The rest can be build as modules.
When you add new hardware, you can just compile the module(s) it needs.
( no need to recompile everything or anything else )

*davidsrsb*
I believe that alsa (almost) allways has to be modular.
When you run "alsaconfig", a few aliasses are added in /etc/modprobe.conf.
Those are used when loading the module(s), and cannot be set if alsa is build-in.
AFAIK this was allways the case...( not sure...)

egag