On Thu, 14 Apr 2005, Franco "Sensei" wrote:
Date: Thu, 14 Apr 2005 11:52:50 -0500
From: Franco "Sensei" <[email protected]>
To: David Lang <[email protected]>
Cc: Krzysztof Halasa <[email protected]>, Adrian Bunk <[email protected]>,
[email protected]
Subject: Re: [INFO] Kernel strict versioning
David Lang wrote:
some config changes are additions, some redefine things.
you are mistakeing the .config file for a symbol table.
No I'm not confusing. As long as the .config has an influence on the
makefiles I get different symbols names.
for example if you compile a kernel with SMP=y you get different code then
if you compile with SMP=n
if you have the same kernel version on identical machines, but with the SMP
option different on the two different machines you cannot use the same
module binary on both of them.
Of course, but It's cleare that machines with SMP are different from a simple
mono-cpu.
It's not an issue talking about smp vs. not-smp. Let's talk about a machine:
it's useless arguing about Cray while I'm talking about a simple environment.
Every kernel has always the distinction about smp. So it's not a big problem.
there are at least a half dozen options besides SMP that have similar
effects.
you would have an ABI for that kernel image, compiled with those options,
and with that compiler. if you change any of those things then your modules
won't work (you have a different ABI
Of course, as I stated, it's a distro's care to use the same gcc and same
switches....
Ok, now you are talking a distro, not linux itself. different subject,
belongs on different lists (and by the way distros already tend to do this
type of thing)
what you are missing is that nobody has any interest in supporting a kernel
ABI, even within a single kernel version. there are just too many
advantages to changeing fundamantal things in the kernel depending on the
config options.
An advantage is the total freedom about the code. Ok, I know. But as long as
the kernel grows, in size and in its use, something more should be
considered. ABI is a step forward companies and people like me in handling
linux easily. API and data structure stability should be something in mind,
since breaking compatibility from 2.6.8 to 2.6.8.1 causes big troubles to
anyone who's mantaining many machines. And if you are in big environments,
you probably use modules which are not in vanilla, and will never be, like
OpenAFS.
Finding a bug in the kernel source and patching it, must be a careful step,
because if I have to mantain 100 machines, and I know that applying the patch
will result in a broken kernel modules, I'm not happy with it. I must go
manually on each machine, apply the patch, recompile the modules... Makes me
think about NOT applying the patch.
first off, if you can deploy a new kernel across 100 machines you can
deploy new modules along with it.
second, if you are applying the patch and know that it doesn't affect
anything that the modules use you don't have to recompile the modules, but
if you want to be safe becouse you don't know what the patch affects then
you replace the modules as well (for all you know the patch affects just a
module, not the base kernel.
I don't know why the default location for the modules, but again you are
assuming that you CAN have a single vmlinuz-2.6 kernel file for all
machines of a given arch.
you can't.
I think we can. Freedom in developing source code is not necessarily stealing
bricks from someone's feet :)
there are just too many config options that change the internals of the
kernel (locking, function call formats, CPU type optmizations, etc) for you
to just have one.
Source compatibility is there. Now, you're talking about issues which are not
your buisness: a binary distribution must take care of how the kernel it's
compiled. As long as it uses the same gcc and switches, it's ok.
Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows how
they're compiled, and they work everywhere. Of course, it has also
kernel-2.6.A-SMP and its modules.
When 2.6.B is released, using ABI will just result in another compilation,
creating the kernel with additions and patches, and distributing them.
Modules .A should work on .B, like I do with OpenAFS, Every kernel update
shouldn't break the magic :)
again you are talking about what a distro chooses to do, go ahead and do
this if you want, but it has no relevance to the kernel mailing list.
This will be my last message on this subject, hopefully you will let this
die or take the conversation to the mailing lists of the distros that you
choose to use.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]