login
Search
With Keith Owens' announcement that kbuild 2.5 is ready for inclusion into the 2.5 development tree, a discussion on the lkml followed. The big complaint was based on Keith Owens decision to not support modversions (versioned symbols) with this release. Martin Dalecki compared the Linux design process to the Solaris design process, the latter intended to illustrate a better method. Alan Cox explained:
"Now I don't actually give a hoot whether you implement the module binding via /proc/kernel.so and C++ like mangling hacks or the _R stuff we do now but don't confuse the Linux approach of putting a few million users before a few binary module ISV's with the Solaris one."
Kai Germaschewski in turn complained about Keith's style of making such a large change and breaking modversions. Keith explains:
"I have been waiting for somebody to raise the "why not do one bit a time" argument for kbuild. That is exactly what I have done! Modversions are completely broken but are not required for a development kernel, they will be done later. There are 89 'FIXME' comments in the Makefile.in files where changes to source code should be done to clean up the include mess, those changes will be done later."
For full details, read on...
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 14:49:24 +0200
Keith Owens wrote:
> kbuild 2.5 deliberately does not support modversions, you can turn it
> on but it does nothing. The original implementation of modversions
> does not fit with the way that people build kernels now (apply patches,
> change configs, rebuild without make mrproper). To do modversions
> right needs a new version of modutils as well, there is no chance of
> that work being started until kbuild 2.5 is in the kernel.
How many years was it that I was telling that symbol versioning is
a silly concept not solving any single problem and the implementation is to say
the least ugly?
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 15:26:08 +0100 (BST)
> How many years was it that I was telling that symbol versioning is
> a silly concept not solving any single problem and the implementation is to say
> the least ugly?
Modversions solves a huge number of problems very very well. The fact that
you don't like it doesn't change the reality of the situation.
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 15:32:35 +0200
Alan Cox wrote:
> Modversions solves a huge number of problems very very well. The fact that
> you don't like it doesn't change the reality of the situation.
Could you name *ONE* please? Maybe the following?
- It's solving the problem of applying quick security
fixes to vendor specific kern src.rpm packeges for the user
very well.
- It solves the problem of too fast kernel compiles as well fine.
- As an added bonus it makes you use
the force flag to insmod more often with binary only modules, which
everybody loves... This gives you the good feeling of polite
questions you have been missing from DOS for so long:
"Do you really wan't to delete this file Y/N"...
- And then we have no better use for our RAM then
storing some extendid redundant string information there of course
as well.
- And of course it is not annoying if you want to move
modules which you have just compiled yourself between
two machines. Or perhaps a compilation host and some testing systems.
Far better sollution then just versioning the kernel release
and expecting people to actually know what they do.
They are finally all loosers, becouse they use a system they
can mess with.
It is far better then providing clean submodule interfaces as well.
And finally it's of course a better sollution then versioning
with the granularity of a whole module, which we just don't
have right now. It would be ridiculous to have some
modules to provide the ABI version information they expose just
to let the clients check it explicitely in far too few bytes like
about 1 or maybe 2. The analogy with shared libraries would be far
too big - becouse of it course turned out there to be not sufficient and
the X11 people didn't show us what true compatibility means and the
glibc people don't know what real man programming is.
What are weak symbols for? Ah yes - we have to hold up the
a.out tradition in it's full glory!
Did I mention that the C++ solution to linker deficiencies is
inferior to module versioning of course as well, becouse
catching the type signature is not what we wan't.
Yes - versioning of every single piece is indeed a very good
solution to the above problems and a nice piece of SW design!
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 16:17:36 +0100 (BST)
> Could you name *ONE* please? Maybe the following?
It handles the case when you have modules that don't get rebuilt as part of
the base kernel. It allows you to build fixed kernel images without spending
ages rebuilding all the modules when they otherwise match
> - As an added bonus it makes you use
> the force flag to insmod more often with binary only modules, which
> everybody loves... This gives you the good feeling of polite
Unrelated IMHO
> - And then we have no better use for our RAM then
> storing some extendid redundant string information there of course
> as well.
Which occupies almost no space
> Far better sollution then just versioning the kernel release
The kernel release isnt useful info. Many interfaces are stable across
multiple kernels, many interface issues depend on things other than kernel
version. Lots of people apply patches and don't change the base kernel
version - in fact its hard to do so
> Yes - versioning of every single piece is indeed a very good
> solution to the above problems and a nice piece of SW design!
I think so. It solves the first 95% of the problem. Solving 100% isnt easy
enough to be worth it. Throwing it out and solving 0% of the problem is
not very bright either
Martin Dalecki wrote:
> > Modversions solves a huge number of problems very very well. The fact that
> > you don't like it doesn't change the reality of the situation.
>
> Could you name *ONE* please? Maybe the following?
It fixes the problem where support people and people who get the
bugreports have
to stare at "impossible" problems for hours and hours to find out that
someone
has insmod'ed a module for a different kernel (be it an athlon module in
a i686 kernel
or someone using perl to replace the built-in kernel version in the .o
file)
From: Richard Gooch
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 09:59:56 -0600
Arjan van de Ven writes:
> someone using perl to replace the built-in kernel version in the .o
> file)
Oh, my! Do people really do that?!?
Regards,
Richard....
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 17:36:26 +0200
Richard Gooch wrote:
> Oh, my! Do people really do that?!?
Yes they do, if they wont for example to get some
PCTEL win chip driver working. No matter what Alan and some others
think is good for them :-).
The main problem with mod-versions is the simple fact
that policy doesn't belong in to the kernel it belongs
in the user space. And mod-version is *just policy*.
See... if some impaired project manager at some
linux distro provider associated with hats,
who does decisions like for example basing the main OS
configuration tools on instable programming languages
like python or perl... does decide that he needs
the functionality of MODULEVERSIONS to get full controll about the
users of his crappy product. Why the hell doesn't he let all this
version checking be done for his own kernel cook-up entierly in
his patched mod-utils? And entierly in USER SPACE? He does
have the full scope of things which need the bless of versioning
over them at his hands and there is *no technical* argument why this
should be done in kernel space at all!
It just DOES NOT BELONG in to the kernel-space.
No matter what percentage of supposed problems it solves and
how many problems it in reality adds...
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 18:15:17 +0100 (BST)
> The main problem with mod-versions is the simple fact
> that policy doesn't belong in to the kernel it belongs
> in the user space. And mod-version is *just policy*.
Nope. modversions are information about the ABI/API and objects referenced
directly or indirectly from them. The policy is entirely in modutils.
Modutils has the power to say "well that looks kind of the same I'll bind
that symbol name".
Kernel -> "Here is a helpful set of ABI compatibility hashes"
Modutils -> "This symbol doesnt match, what do we want to do about it. Lets
fail". It could equally pick something looking similar.
> It just DOES NOT BELONG in to the kernel-space.
People who start using capital letters always seem to have emotional rather
than logical reasons for their argument.
Alan
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 18:30:38 +0200
You are wrong.
ar r module.a module-symbol-versions-copyright-or-whatever
ar r vmlinuz.a symbol-versions-from-System.map
(Perhaps the ld variant with some section magic would be
looking prettier and technically more correct.)
Shared libraries for example don't look up stuff like this inside
themselfs. (Unless you look at DLL stubs...)
It's the ld.so programm which maintains such data.
modutils don't do anything different from classical late binding.
The natural place for such maintainance work could be for example
the init process, which serves already pretty a similar role for
the kernel like ld.so does for user land applications. It would
provide a convenient point for possible synchronization...
Another analogy is the rpm dependency maintainance.
It's the rpm program - which does checking here and not
the actual application itself during the file-system install.
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 19:20:03 +0100 (BST)
> Shared libraries for example don't look up stuff like this inside
> themselfs. (Unless you look at DLL stubs...)
Nor does the kernel. Internal symbols are already resolved
> It's the ld.so programm which maintains such data.
> modutils don't do anything different from classical late binding.
Indeed
> The natural place for such maintainance work could be for example
> the init process, which serves already pretty a similar role for
Well actually the logical place to do it is in modutils. Which is where
we do it right now. We even precompute dependancies with depmod much like
the dynamic link caches
> Another analogy is the rpm dependency maintainance.
> It's the rpm program - which does checking here and not
> the actual application itself during the file-system install.
Actually for dynamic stuff the application also does some of it for late
binding and when triggers are used for relations between packages
All of which says the current modutils method is correct
On Thu, May 02, 2002 at 05:36:26PM +0200, Martin Dalecki wrote:
> See... if some impaired project manager at some
> linux distro provider associated with hats,
> who does decisions like for example basing the main OS
> configuration tools on instable programming languages
> like python or perl... does decide that he needs
> the functionality of MODULEVERSIONS to get full controll about the
> users of his crappy product. Why the hell doesn't he let all this
> version checking be done for his own kernel cook-up entierly in
> his patched mod-utils? And entierly in USER SPACE? He does
> have the full scope of things which need the bless of versioning
> over them at his hands and there is *no technical* argument why this
> should be done in kernel space at all!
Thank you for this insult and welcome to my .procmailrc
Oh and please don't forget your medicine tomorrow as you did today..
> It just DOES NOT BELONG in to the kernel-space.
That's why it's done by modutils.
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 18:53:23 +0200
Arjan van de Ven wrote:
>>It just DOES NOT BELONG in to the kernel-space.
>
> That's why it's done by modutils.
Last time I checked on Linux:
[root@kozaczek j2me]# ls -l /proc/ksyms-r--r--r-- 1 root root 0 Mai 2 19:42 /proc/ksyms
Compare this with the following on Solaris:
www01:/kernel/drv# ls sy sy.conf
sy sy.conf
www01:/kernel/drv# file sy
sy: ELF 32-bit MSB relocatable SPARC Version 1
www01:/kernel/drv# cat sy.conf
#
# Copyright (c) 1992, by Sun Microsystems, Inc.
#
#ident "@(#)sy.conf 1.4 93/06/03 SMI"
name="sy" parent="pseudo" instance=0;
www01:/kernel/drv#
www01:/kernel/drv# nm sy
0000000000000014 T _fini
0000000000000028 T _info
0000000000000000 T _init
U cdev_ioctl
U cdev_poll
U cdev_read
U cdev_write
....
0000000000000278 T syclose
0000000000000488 T syioctl
0000000000000140 T syopen
00000000000005b0 T sypoll
0000000000000280 T syread
0000000000000384 T sywrite
www01:/kernel/drv# strings sy
Indirect driver for tty 'sy'
www01:/kernel/drv#
And then think about the fact that they are able to even *patch*
running kernels. There is no way I can be convinced that the whole
versioning stuff is neccessary or a good design for any purpose.
From: "David S. Miller
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 10:48:17 -0700 (PDT)
> And then think about the fact that they are able to even *patch*
> running kernels. There is no way I can be convinced that the whole
> versioning stuff is neccessary or a good design for any purpose.
Hint: they never changes their ABIs for drivers. This is why
they can't fix several large scale bugs in their OS. When the
fix would break every third party Solaris driver on the planet
they simply don't do the fix until the next major relase of the
OS.
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 19:42:05 +0200
David S. Miller wrote:
> Hint: they never changes their ABIs for drivers. This is why
> they can't fix several large scale bugs in their OS. When the
> fix would break every third party Solaris driver on the planet
> they simply don't do the fix until the next major relase of the
> OS.
Yes I know. But my main point is that they maintain the
whole module symbol and dependency data entierly in user space
and MODULEVERSION in the *linux kernel*, just simply isn't worth the
trouble. Similarly the whole Tainted not tained MODULE_AUTHOR
and so on information simply shouldn't me maintained
in precious kernel RAM space.
Information about module dependencies does get resolved at
the proper level: not centralized in a single one Makefile
alike repository but by an *.conf file placed alongside of it.
The module objects them-self look very much like a simple *stripped*
ELF shared objects and don't contain any hack-in of string arrays
in the .text segment just to provide data which can be trivially
reconstructed and maintained in user space. Module request handling for hot
pluggable devices for example is done entierly inside user
space and so on...
Version consistency get's handled at the proper level - namely
the file packaging. Once and not repeatedly during every time
a particular module get's loaded and so on... And then there is
simple late kernel binding. After all having a messed up /kernel
dir is not a single bit more dangerous then just having a
trashed vmlinuz file.
Overall even the fact aside that they have a much stronger policy
about releases, the overall design is much cleaner then on the
linux side of the world.
Gosh - the whole /devices file-system is an old hat for Solaris.
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 20:11:59 +0100 (BST)
> Yes I know. But my main point is that they maintain the
> whole module symbol and dependency data entierly in user space
Actually thats also incorrect as far as I can tell
Alan
From: David S. Miller
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 11:49:32 -0700 (PDT)
From: Alan Cox:
> Actually thats also incorrect as far as I can tell
To the best of my knowledge, they do something similar
to what modutils does right now when depmod is run, but
at module load time. Ie. "oh module X needs symbol Y, who
provides symbol Y, lets load that first then retry X"
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 19:33:06 +0100 (BST)
> And then think about the fact that they are able to even *patch*
> running kernels. There is no way I can be convinced that the whole
> versioning stuff is neccessary or a good design for any purpose.
I wouldnt pick Solaris as an example. A long time ago they fixed a bug
in the streams code I found that let anyone reconfigure networking. It was
fixed in a day then not released for a year. It cost Sun a lot because
several customers wisely asked why it hadn't been fixed and went with
other products. To this day Sun has never explained officially why it took
a year to fix but I've been informed off the record by sun people I trust
that it was because it broke their module abi so had to be held over for
the next release
Now I don't actually give a hoot whether you implement the module binding
via /proc/kernel.so and C++ like mangling hacks or the _R stuff we do now
but don't confuse the Linux approach of putting a few million users before
a few binary module ISV's with the Solaris one.
Alan
On Thu, 2 May 2002, Keith Owens wrote:
> kbuild 2.5 deliberately does not support modversions, you can turn it
> on but it does nothing. The original implementation of modversions
> does not fit with the way that people build kernels now (apply patches,
> change configs, rebuild without make mrproper). To do modversions
> right needs a new version of modutils as well, there is no chance of
> that work being started until kbuild 2.5 is in the kernel.
I would like to object here. Getting dependencies right for modversions is
very much possible in principle, after all modversions are generated in a
deterministic process. (It's also possible in practise, though it's quite
a bit of work).
You're right that modversions are not perfect. It's possible that the ABI
changes, but the checksum doesn't, but that's very rare. It's also
possible that the ABI does not change but the checksum does. That happens
a lot, but it's not really a big problem because that (if done right) will
just cause spurious rebuilds - correctness isn't affected.
Of course, for people who are patching their kernels a lot, modversions
(again if done right) are a pain in the a**, since they cause a lot of not
really necessary rebuilds. But people who do that supposedly think they
have some idea of how the kernel works and can turn it off - if they get
bitten by ABI changes then, it's their problem.
Modversions is really essential for distributions, where it's badly needed
to keep users from causing hard to track down crashes by inserting
self-compiled or obtained from whereever else modules into a kernel which
was compiled with a different config.
--Kai
From: Alan Cox
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 16:19:00 +0100 (BST)
> possible that the ABI does not change but the checksum does. That happens
> a lot, but it's not really a big problem because that (if done right) will
> just cause spurious rebuilds - correctness isn't affected.
ccache is your friend on that one.
> Of course, for people who are patching their kernels a lot, modversions
> (again if done right) are a pain in the a**, since they cause a lot of not
> really necessary rebuilds. But people who do that supposedly think they
ccache is still your friend 8)
Alan
From: Pavel Machek
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 3 May 2002 00:57:44 +0200
Hi!
> ccache is still your friend 8)
What is ccache?
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
From: Vikram
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 3 May 2002 01:33:34 -0700 (PDT)
> What is ccache?
maybe this?
<snip>
ccache is a compiler cache. It acts as a caching pre-processor to C/C++
compilers, using the -E compiler switch and a hash to detect when a
compilation can be satisfied from cache. This often results in a 5 to 10
times speedup in common compilations
</snip>
Vikram
From: Keith Owens
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 03 May 2002 22:07:14 +1000
Firstly kbuild 2.5 removes the need to make clean or make mrproper for
most compilations. You need to make mrproper when changing to a new
architecture in the same directory (it is much better to use a separate
object directory for each architecture), but apart from that you should
not need to make clean or mrproper. IMNSHO having to issue make clean
is a sign that your build system is broken, relying on human
intervention in an automated build is falt out wrong. Automatic
detection of an arch switch is on the enhancement list for kbuild 2.5.
Secondly kbuild 2.5 keeps objects that were built but are not currently
selected, it just does not link or install them. Build a kernel,
disable a set of drivers, build the kernel and it will just bump the
version number and relink vmlinux. Enable the drivers again, kbuild
2.5 does not need to compile them, they are still there, it just bumps
the version number and relinks vmlinux. Same with installing modules.
Various .tmp files list the objects and modules required for the
current .config.
So kbuild 2.5 removes the need to make clean after patches, changing
configs, etc. It gets it right without human intervention.
kai said:
> I would like to object here. Getting dependencies right for
> modversions is very much possible in principle, after all modversions
> are generated in a deterministic process. (It's also possible in
> practise, though it's quite a bit of work).
To what are you objecting? You aren't disagreeing with Keith here. He
merely said that there's no chance of him working on modversions until
the newer build system that's sane w.r.t. dependencies is incorporated.
> Modversions is really essential for distributions, where it's badly
> needed to keep users from causing hard to track down crashes by
> inserting self-compiled or obtained from whereever else modules into a
> kernel which was compiled with a different config.
Distributions are unlikely to be shipping 2.5 kernels. As long as
modversions can be reimplemented properly by the time 2.6 is released,
what's the harm in disabling it for a while?
It's hard enough to keep kbuild-2.5 up to date with recent kernels as it
is; let's not keep moving the goalposts by adding new requirements for the
initial adoption -- once it's in and the makefiles are maintaining
themselves, we can concentrate on reimplementing the niche features.
--
dwmw2
From: Kai Germaschewski
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 10:40:49 -0500 (CDT)
On Thu, 2 May 2002, David Woodhouse wrote:
> To what are you objecting? You aren't disagreeing with Keith here. He
> merely said that there's no chance of him working on modversions until
> the newer build system that's sane w.r.t. dependencies is incorporated.
Well Keith's statement (as I read it) is: modversions are broken, I don't
support them. My statement is: modversions work 95% of the time, why throw
them out?
That doesn't mean the could be replaced by something which works more than
95% of the time later (though 100% will be impossible to achieve anyway
IMO).
> Distributions are unlikely to be shipping 2.5 kernels. As long as
> modversions can be reimplemented properly by the time 2.6 is released,
> what's the harm in disabling it for a while?
>
> It's hard enough to keep kbuild-2.5 up to date with recent kernels as it
> is; let's not keep moving the goalposts by adding new requirements for the
> initial adoption -- once it's in and the makefiles are maintaining
> themselves, we can concentrate on reimplementing the niche features.
I merely disagree with the way how things are done here. Al Viro doesn't
go like: here's a new VFS, everything is handled differently now - oh, and
for the time being symlinks don't work, I'll fix that until 2.6 (I know
this is a a bit extreme, but you get the point).
If Keith went like fixing issues one at a time, he wouldn't have that huge
patch now, which replaces everything and is hard to keep up-to-date.
There's a lot of orthogonal issues with kbuild which can be solved one at
a time, e.g. correct dependency generation, cleaning up Makefiles (like
getting rid of the explicit list-multi link rules), spurious rebuilds,
building built-in and modular objects in one pass, non-recursive make, ...
My understanding is that the Linux way would have been the latter, going
one step at a time, as Al Viro demonstrates perfectly with the VFS layer.
This way it would also have been possible to select which features are
considered worthwhile and which aren't - not "you have to take it all or
nothing"
Anyway, just my opinion, and yes, I'm admittedly preoccupied.
--Kai
From: Keith Owens
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 03 May 2002 09:40:34 +1000
On Thu, 2 May 2002 10:40:49 -0500 (CDT),
Kai Germaschewski wrote:
>Well Keith's statement (as I read it) is: modversions are broken, I don't
>support them. My statement is: modversions work 95% of the time, why throw
>them out?
Build a complete kernel with modversions. Apply a patch or change a
config option that changes a structure size. make bzImage, reboot.
modversions are _not_ rebuilt. The kernel and modules were built using
different ABIs but modversions claims that they are identical.
Third party code is built using a copy of .config and modversions.h.
This assumes that modversions.h was generated using the same .config,
but it is not checked. The module _may_ have used a different config
but asserts it was built using the same ABI as the kernel (same
modversions). Result is a module that appears to match the kernel,
when really all you know is that the user claims it matches the kernel.
People think that modversions gives a strong check on ABI compatibility
for third party modules. Wrong! What it really gives is a weak
assumption that the user copied two files that are in sync.
Modversions only detect ABI changes if you make mrproper after any
change that affects the symbol versions. That has to be done manually,
it cannot be automated. Generation of new symbol versions requires a
recompile of everything marked export-objs after any source or config
change. But there is no way of telling where the versioned symbols are
consumed, so any change to any versioned symbol requires a complete
kernel rebuild to ensure that every consumer picks up the new version.
Make any change, make mrproper, rebuild from scratch, it is the only
way to ensure that modversions are correct. Modversions are fine for
distributors, a pain in the neck for everybody else.
95% working? More like 95% broken!
I know how to do ABI versioning right. But there is no chance of me
starting work on the correct method of ABI versioning until kbuild 2.5
is in.
>If Keith went like fixing issues one at a time, he wouldn't have that huge
>patch now, which replaces everything and is hard to keep up-to-date.
>There's a lot of orthogonal issues with kbuild which can be solved one at
>a time, e.g. correct dependency generation, cleaning up Makefiles (like
>getting rid of the explicit list-multi link rules), spurious rebuilds,
>building built-in and modular objects in one pass, non-recursive make, ...
I have been waiting for somebody to raise the "why not do one bit a
time" argument for kbuild. That is exactly what I have done!
Modversions are completely broken but are not required for a
development kernel, they will be done later. There are 89 'FIXME'
comments in the Makefile.in files where changes to source code should
be done to clean up the include mess, those changes will be done later.
Changing from a recursive to non-recursive make is the big change in
kbuild 2.5. If you think that you can do non-recursive make without
significant changes to the Makefiles, show me the code.
If you think that you can fix all the problems listed in
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2
without making significant changes to the entire kbuild system, show me
the code.
I have no patience with people who pick the small problems out of
kbuild and fiddle with the Makefiles without considering the entire
problem list. That is a classic case of ignoring the big problem and
concentrating on the little problem that you know how to fix.
kbuild 2.5 fixes _all_ the problems listed in the history file, except
for modversions which will be done later. Once you decide to fix the
big problems, you will realise that fiddling with the old system to fix
the little problems is a waste of time and effort.
From: Martin Dalecki
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 03 May 2002 01:25:50 +0200
Keith Owens wrote:
> I know how to do ABI versioning right. But there is no chance of me
> starting work on the correct method of ABI versioning until kbuild 2.5
> is in.
It's shown in the syscall part of the kernel :-) Just don't provide
a too big ABI and stick to it is one possible strategy.
And of course I'm sure you recognize that what we could use is ABI *checking*
and not ABI *versioning* thingee. If one really really want's to do this the
only true one way, well the solution is.... for example CORBA IDL and stuff
if you divide the remote part of CORBA out.
And hell I'm not expecting an ORB to appear in the kernel any time soon.
(However I remember someone once implementid such a beast...)
From: Dave Jones
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 23:42:02 +0200
On Thu, May 02, 2002 at 11:34:44PM +0200, tomas szepe wrote:
> '/usr/include/asm' points to '/usr/src/linux/include/asm'
Therein lies your problem.
/usr/include/asm should NOT be a symlink. At least, not in this century.
From: John Covici
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 2 May 2002 21:19:53 -0400 (EDT)
So what should it point to? I have had more trouble when some Debian
package made it not a symlink and if I tried to compile something
which needed correct headers for the version I am using I get very
strange errors which are hard to diagnose.
From: Keith Owens
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 03 May 2002 11:33:27 +1000
Linus has spoken. /usr/include/{linux,asm} must not be a symlink that
points to kernel code that is updated. glibc must contain the linux
and asm files that were used to build glibc and those files must not
change until you change glibc. glibc must take a copy of the kernel
headers at glibc build time or (much less desirable) it can symlink to
a set of kernel headers that are guaranteed to never change.
Having glibc linking to some random set of kernel headers is a recipe
for disaster. kbuild 2.5 deliberately handles the asm symlink
differently from the old kbuild system, to detect and correct broken
installations.
From: tomas szepe
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Fri, 3 May 2002 03:39:41 +0200
Fair enough. I suggest, though, that you put a similar explanation
into kbuild 2.5 documentation.
T.
