Let's take the six permutations of changes and walk through what can go wrong with them.

a) Code was in the core kernel, but is being turned off entirely - stale objects could still include hooks to whatever you just removed.
b) Code was in the core kernel, but is being made into a module - stale objects could still include symbols for code which will now be in a module. Load a module with symbols that are already present in the kernel and *bang* it'll kick it right back out.
c) Code was a module, but is being disabled entirely - no problem here. make modules_install wipes the target directory before installing everything, so the now no-longer-compiled module quietly goes away and the kernel was unaffected by the change.
d) Code was a module, but is being moved into the kernel - Stale objects in the kernel might result in things hitting a dead end when they should continue execution through the code now added to the kernel.
e) Code was never enabled before, but is to be built as a module - same effect as C, actually.
f) Code was never enabled before, but is to be built into the kernel - same effect as D.

I was originally somewhat of the impression that cases a, b, and d would result in the Makefiles figuring out that some objects may need rebuilding, but apparently there are ways for code to be more clever than Makefiles can easily figure out. (To spot everything, Makefiles would have to test not only the object they're worrying about, but every other object that could affect it, and every other object that could affect that, and so on.) From reading the LKML I finally just gave up worrying about it, since the "FTW" scenario is to build as much as possible as modules anyway, the times when someone might need to actually clear things out should be few and far between (maybe twice a year for me, maybe). Building entirely monolithic kernels is just as dead as the last pope.

...as far as I know, vmlinux isn't compressed, and bzImage is (with bzip2).

Maybe I didn't understand what a stale object actually is, but anyway isn't a module by definition a non-dependant part of software, which can be loaded anytime you want, without taking care of what configuration kernel really loads it? As I have understood till now only kernel can call module functions and not vice versa. It (module) shouldn't have hooks back to the calling program if it isn't programmed with this purpose specifically like to intercept some syscalls, which is a different case.


EDIT:

And why f is d?

In addition, never checked make modules source, but doesn't it clean already made modules before making new ones? And I've always try to run solid kernel except iptables which do not work if they're built into the core. What's wrong with solid ones?

stale object: (mostly) any *.o (object) file that was previously compiled using directives which may very well no longer be in place.

Sure, you can load a module without worrying about the configuration of the kernel, provided they don't have features that overlap each other. You can see what happens when this is going on by booting the huge kernel, and then trying to load the USB mass storage modules (which has been reported on this forum from people several times now). Just like when you include two differing versions of the sort-of same library into one binary (ever seen what happens when you link libgtk+-1.so and libgtk+-2.so into one binary at the same time?) you can have a equivalent of a symbol collision in the kernel quite easily.

The thing that I suspect people overlook is that there is not a 1:1 ratio of config items to chunks of kernel code. There's numerous things which pull in more than one piece of code, and some which pull in bits of code depending on whether or not they're already being pulled up.

Let's say that A pulls in B, and that C also pulls in B if nothing else has done so. Now we'll say that A has in fact pulled B into the kernel, and then C gets compiled later with a different config that leads it to believe it needs to pull in B still. C+B modprobing into A+B equals BLOOEY!. NOW at least, the configurator seems to prevent really dim things going awry there, but in 2.4.x kernels I don't think things were checked as carefully (or were probably done in an entirely different way) because numerous times with 2.4 I managed to set up configurations involving me trying to be selective about which USB modules/drivers I built in, just to get a kernel that wouldn't even compile without dying halfway through because of some module I'd skipped enabling which resulted in (apparently) unexpected things being missing for the parts I did compile.

Think of all the blocks of code like literal blocks with wires sticking out of them. Compiling them solders the wires together that link all the pieces, and snips off the leftovers that don't go anywhere. Adding a new block after the kernel is finished could leave you with nothing to connect the wires to, or wires connected to more than one place at a time that shouldn't be (figuratively speaking).

It doesn't wipe anything. If you go into menuconfig and add one new module to be built, when you run `make modules` it'll build that module alone and be done with it.

As to entirely monolithic kernels, there's really no point anymore. You just get a big kernel that might be too large to load with no benefits. It was proven wrong ages ago that you couldn't force the kernel to load a module anyway (rootkit modules, anyone?). You can *add* or *blacklist/remove* modules later if you need to change something, but you have to build a whole new kernel if you're going monolithic. (Which means that even though they're lottery odds, you invite the chance that some obscure compiler bug could manifest throughout the entire kernel instead of just the new module.) There's no meaningful level of overhead involved in using modules, and now with kmod and udev doing what they're supposed to, they spring up for pretty much everything you have without prompting (so less chance of the intern loading the wrong driver module). If I were looking to make a super-super-teeny-tiny kernel, or one for an appliance whose hardware facilities would never ever possibly change (like a specific model of PDA or router), I'd probably go monolithic, but nowadays even my PDA has 8Mb of RAM in it, which is more than the amount of RAM the first machine I assigned an IP address to and put online had. I'm not going to get quibbly over anything less than 100K without good reason.

I've read your response. Thank you. Will read it again tomorrow with clear head.

The problem I see with building modularized kernel is that you actually don't know whether this module is used or not and why is it required at all (because udev and other tools do all the work for you (I don't use these, neither udev nor hotplug)). You're (not specifically you, but people) building hundreds of modules without really considering if they're useful or not. Because I specifically build kernel for my box and it doesn't change a lot (in the last four years this box had only mb changed, cause I've burnt USB controllers), I consider monolithic kernel a wise choice. Yeah, there isn't noticeable speed or memory gain, but still...

BTW, why such tools as insmod and rmmod exist if modularized kernel is so good?

Finally found time to reread.

AFAIU (understand), f can't be d, just because f part was not referenced from any other parts of the kernel, adding it to the kernel shouldn't make wrong (stale) references to its previous location.

It's strange that bzImage is called x86 boot sector and not simply bz2 archive.

This applies only to modules and not to solid kernel, doesn't it? BTW, we can control which modules are modprobed with what options, so I can't see a problem in C modprobing B again (I'm not even sure if kernel lets you to modprobe same module again. Even if it is possible, you can always remove additional B line).