Re: [INFO] Kernel strict versioning

From: Franco \"Sensei\"
Date: Thu Apr 14 2005 - 17:54:07 EST


Horst von Brand wrote:
No I'm not confusing. As long as the .config has an influence on the makefiles I get different symbols names.

Nope.

I don't understand. The .config drives the kernel build, I don't get XFS functions and names if I don't compile it. I have different symbol names... At least, that's what I understand... and that's what happens... Never the same names on different kernels.

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.

Yes, ok.

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.

Yes, but as long as you keep with the same configuration, no problem should arise in changing the kernel version.

Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.

I probably expressed myself badly. I don't mean anyone having the same configuration... why on earth should it be?

Source compatibility is there.

Sort of.

I hope! :)

And A doesn't have some options I'd like, and others you loathe.

That's why you recompile, but why should you throw your other modules not included in the kernel release?

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.

That's weird... why should things really change so drastically if the external interface still remains the same? It's probably a matter of abstraction...

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/.

Ok.

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.

I'd really like to know... I'm naive? Yes :) Of course, other than ``more work'', but technical disadvantages...

--
Sensei <mailto:senseiwa@xxxxxx> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:sensei_sen@xxxxxxxxxxx>

Attachment: signature.asc
Description: OpenPGP digital signature