No I'm not confusing. As long as the .config has an influence on the makefiles I get different symbols names.
Nope.
And kernels compiled with one compiler are different than those compiled
with another. And if you have preemption they are different. Don't forget
about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
in assorted debugging options. On some architectures you have several
possible (reasonable!) page sizes.
Define "simple environment". Even Red Hat (they are /very/ interested in a
single kernel image, as it cuts down testing and bug tracking etc!) ships
half a dozen different kernels, tailored for different configurations. And
you'll find external modules (like for NTFS) compiled separately for each
of them.
Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.
Source compatibility is there.
Sort of.
And A doesn't have some options I'd like, and others you loathe.
creating the kernel with additions and patches, and distributing them. Modules .A should work on .B,
Iff nothing changes. That isn't usually the case.
The problem is that giving that guarantee costs developer time and
flexibility. The gain (given that source for recompilation is freely
available) is so minuscule that the consensus is that it just isn't worth
any extra hassle /at all/.
And the decision to design thusly is completely conscicious, it is not a
random "it just turned out this way by mistake".
I just see advantages on ABI, and I think it's not bad talking about it...
I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
Attachment:
signature.asc
Description: OpenPGP digital signature