-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
I regret having to do this but Linus has left me with no other options.
Short form (read all of the long form before replying)
If you want a kernel build system that is :-
Faster.
Is easier to use for all cases.
Easier to debug.
Is fully documented.
Has better error checking.
Fully supports host programs and boot loaders as well as the kernel.
Supports read only source tree.
Supports separate source and object trees.
Provides the data that Rusty needs to standardize boot and module parameters.
Supports compilation of third party code.
Copes with timestamp skew.
Positions us for correct module symbol versions.
Is automatic.
Above all else, is 100% accurate.
Then tell Linus that you want kbuild 2.5.
Don't tell me, I already know. Tell Linus, he is the bottleneck.
OTOH if you are happy with a kernel build system that is :-
Slower.
Is harder to use for special cases.
Has almost no debugging facilities.
Has out of date documentation.
Has limited error checking.
Has incomplete tracking for host programs and boot loaders.
Might support read only source tree, one day.
Might support separate source and object trees, one day.
Might provide the data that Rusty needs, one day.
Will not support compilation of third party code.
Will never cope with timestamp skew.
Is stuck with incorrect module symbol versions.
Relies on manual intervention.
Above all else, is demonstrably inaccurate.
Then do nothing and live with the restrictions of the existing kernel
build system.
It is a sad day when a fully tested and documented system that is
faster and, above all, more accurate, cannot get into the kernel.
Linus is judging kbuild 2.5 on its popularity and on personalities, not
on its technical merits.
======================================================================
Long form (read all of the long form before replying)
Q01. Really 100% accurate?
A01. Yes. If not, it is a bug which I will fix.
Many of the problems in the existing build system are in the too
hard basket, errors are ignored because they are too difficult to
fix. Every known error in the existing build system has been
corrected in kbuild 2.5.
Q02. Really faster than the existing system?
A02. Yes. kbuild 2.5 provides more features, provides more
information, is more robust and it still manages to be faster
than the existing build system. For sample timings, see
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-21/1208.html
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-21/1236.html
Q03. How do I use kbuild 2.5?
A03. Go to http://sourceforge.net/project/showfiles.php?group_id=18813
and download at least three patches. You need the latest -core
patch, plus the common and architecture dependent patches for the
kernel you are working on. The current version of kbuild 2.5 is
Release 3.0, that may change.
Read the start of each patch for any special instructions. In
general you apply -core, -common and $(ARCH) patches in that
order to a clean kernel to get kbuild 2.5 support.
After applying the patches, I suggest you read the copious notes
in Documentation/kbuild/kbuild-2.5.txt. For the impatient :-
Build in the same tree as the source.
cd source/tree
make -f Makefile-2.5 oldconfig installable
Build in a separate object tree.
export kbuild_OBJTREE=/full/path/to/object/tree
export kbuild_SRCTREE_000=/full/path/to/source/tree
make -f $kbuild_SRCTREE_000/Makefile-2.5 oldconfig installable
Add -jN as required. Unlike the existing build system, kbuild
2.5 is parallel safe.
If you do not specify any target on the command line, the default
is 'installable', i.e. build a complete system ready to install.
If you have already built the config, just do
make -f $kbuild_SRCTREE_000/Makefile-2.5
Q04. Why are there multiple patches?
A04. The -core code implements all the hard work of kbuild 2.5. The
core is independent of the kernel, it will even run on 2.4
kernels.
The -common patch is specific to a particular kernel. It
contains all the architecture independent makefile changes, plus
some bug fixes to code that is shared between the existing build
system and kbuild 2.5.
The arch dependent patches are tied to a particular architecture,
they contain all the architecture dependent makefile changes.
You can mix and match the latest core code with any of the kernel
specific patches.
Q05. How do I build for multiple architectures?
A05. Download and apply the arch specific patches that you need.
There is no overlap between arch patches so it is always safe to
apply patches for more than one architecture.
If there is no arch specific patch for the kernel version you
want, try the arch patch for the next kernel version down. Arch
specific patches do not change very often and you can sometimes
get away with using an older arch patch on the later kernels.
Hint: kbuild 2.5 supports separate source and object trees. This
lets you build for i386 in one object tree and build for
sparc64 in a second object tree, all from the same (read
only) source tree. You can even run both builds at the
same time. The only restriction is that you cannot use the
same object directory for two different architectures.
Q06. Why do I have to use make -f Makefile-2.5?
A06. Compatibility glue with the existing build system. As currently
structured, kbuild 2.5 does not replace the existing build
system. Instead it coexists with the existing system. This
allows parallel testing of the two build systems, and is useful
for architectures that are not up to the latest kernel yet.
Eventually kbuild 2.5 will replace the existing system and all
the compatibility glue will disappear. At that time, the
makefiles get renamed from Makefile-2.5 to Makefile.
The fact that make *config says 'now run make dep' is also
compatibility glue. kbuild 2.5 has no make dep processing but it
uses some existing configuration code.
Q07. Why is [b]zImage part of the config?
A07. In the current system, installation is a poor relation of the
build system. Each architecture has their own install targets
with their own special rules. None of the install targets check
that what is being installed was built correctly.
In kbuild 2.5 the install target is a fully supported part of the
build. Not only is [b]zImage (and all the other targets) part of
the config, the config also supports installation to somewhere
other than /, plus optional rules for installing the config and
System.map at the same time as the kernel and modules. This
significantly improves support for cross compilation.
A nice side effect of putting all the install information in
.config is that building a new kernel is as simple as
cp previous_config .config
make ... defconfig installable && sudo make install
Q08. Why support third party code?
A08. Like it or not, significant chunks of the kernel code are not in
the kernel tree. This ranges from non-GPL code through new
versions of drivers and filesystems to entire architectures that
are not yet ready for inclusion in the kernel.
The current build system does not support third party code. Each
developer has to supply their own build instructions, then users
have to manually follow those instructions. This is a continual
source of questions and a significant source of unnecessary bug
reports.
kbuild 2.5 has full and official support for compiling from
multiple source trees. Simply follow the kernel directory
structure for the third party code, set one kbuild variable and
the third party code is treated as any other bit of kernel code.
This support simplifies the maintenance effort for developers who
are working with multiple large patches. By separating each
patch into its own sparse source tree and logically pulling them
together at build time, each patch can be kept separate but used
in a single kernel. It removes the need to have multiple copies
of the base kernel tree, each with a different patch applied and
removes the need to copy changes between trees.
Q09. What is the timestamp problem?
A09. 'make' relies on timestamps never going backwards. This is
reasonable for small projects which do not use source
repositories, it is not valid for large projects building over
NFS, spread over multiple trees and using SCM systems.
When you build over NFS there is always the possibility of
timestamp skew between the source and build machines. Time
synchronization helps but cannot totally remove the problem.
A larger problem is the increasing use of source repositories for
the kernel. When a file is checked out of a repository, many SCM
systems reset the timestamp to when the file was checked in.
Standard 'make' processing gets totally confused by this, which
results in an incorrect build.
Another source of timestamp skew is the support for third party
code which is compiled outside the kernel tree. A user can
switch from kernel+other trees to just the kernel tree. If there
was any overlap between the trees then removing the other tree
exposes the older kernel files, in effect the timestamps go
backwards.
The desire to overcome the timestamp problem is one of the main
reasons behind the use of a kbuild database. kbuild 2.5 records
all the timestamps and detects any timestamp change, either
forwards or backwards.
There is a good reason that all the projects that are trying to
replace make have given up on using timestamps as the only way of
checking what has changed. Nobody believes that timestamp alone
is accurate on large projects.
Q10. What special cases are a problem for the existing system?
A10. Almost any subsystem that is split over multiple directories is a
problem. The existing system is heavily tied to the notion that
everything is in one directory. It is difficult to build a
module from objects in multiple directories without detailed
knowledge of the kbuild internals. Makefiles have to specify
under what conditions the sub directories are entered, then this
information is repeated in each sub directory. Each makefile
that depends on another directory must ensure that the other
directory is fully processed before this directory can complete
its processing.
All host programs and boot loaders are special cases in the
existing system. They do not get command tracking nor full
dependency tracking, so changes that affect these objects can be
overlooked.
None of this is a problem in kbuild 2.5. Removing the recursive
make and building a global makefile automatically exposes all the
dependencies and removes all the manual controls that are
scattered through the existing system. Host programs and boot
loaders are fully fledged members of the build community, and get
all the command and dependency tracking that the kernel gets.
Q11. What extra debugging does kbuild 2.5 have?
A11. The kbuild 2.5 database contains _all_ the information about the
kernel build. This includes the inter dependencies of files, how
objects are linked, the commands used to build each object etc.
There is a program to dump that database in text format for easy
debugging.
The various pre-processing programs have verbose modes so you can
see exactly what they are doing and why. They also have norun
modes for debugging without making changes.
.tmp_vmlinux_order lists the entire set of objects that go into
vmlinux, in the order that they are linked. No more guessing
about which object will initialize first.
In addition to .tmp_vmlinux_order, there are equivalent listings
for host programs and boot loaders, as well as modules.
.tmp_select lists everything that was selected, together with
extra flags, how individual objects are to be linked, which
objects export symbols etc. It is the mapping from .config to
what will be built and how.
Q12. Why change all the makefiles to a new syntax?
A12. Primarily to get away from relying on make for all the
processing. make can never cope with timestamps going backwards,
that problem has to be solved outside make and the program that
solves this problem needs all the information.
This will be the last time that the makefile syntax has to
change. A fundamental problem with the existing system is that
we are not really using makefiles. Instead we use magic
variables which are interpreted by Rules.make.
Every time that there is a major change to Rules.make, every
Makefile has to be changed to suit. The really annoying part is
that _what_ we want to do has never changed, only _how_ it is
done has changed, but that still requires global changes. What
we want to do is build objects as modules or built in and link
them in a defined order, all dependent on config settings. The
bulk of kernel developers should not have to care about _how_ the
kernel is built, but the current system forces them to know the
internal details of kbuild.
Over the years there have been at least four different ways of
specifying what is to be done. Each time this occurred,
everybody had to learn a new way of writing Makefiles and all
Makefiles had to be changed. The most recent example is Kai's
changes from 2.5.15 to 2.5.19. That 'clean up' to Rules.make
required changes to 392 Makefiles. If you continue with the
existing build system and try to handle separate source and
object trees then yet more makefile changes will be required.
kbuild 2.5 Makefile.in files take a completely different
approach. They define _what_ you want to do and leave it up to
the core code to work out _how_ to do it. In other words, we
finally have a clean interface between the developers who want to
write makefiles and the kbuild group who support them.
No more global syntax changes when the kbuild logic is changed!
To prove my point, the core code in kbuild 2.5 has had three
major releases, getting faster each time. None of those releases
required changes to the Makefile.in files, the only changes were
to handle new kernel files and directories.
Q13. Why still use make?
A13. I looked at all the make replacements that I could find. None of
them could cope with the unusual kernel requirements. The kernel
has a two level dependency, rebuilding depends on both file
changes and config changes. Plus we want to rebuild only the
affected files.
Many of the replacements required new tools such as Perl or
Python. The kernel build is heavily constrained on what tools it
requires, I did not want to add yet another one. Don't let the
fact that kbuild 2.5 contains yacc and lex files fool you, the
generated C code is shipped so only the kbuild maintainers
require the extra tools, not kbuild users.
It turns out that once you build a global makefile and take care
of the timestamp problem and the two level dependencies in the
pre-processing code, make does a good job on the actual build.
It is fast and accurate in its own domain, as long as you give it
all the data.
Q14. kbuild 2.5 does not support modversions.
A14. The existing modversion code is not being used for the job it was
invented to handle, unfortunately it does not work correctly for
what people are using modversions for. Module symbol versions
were originally invented to stop users loading SMP modules into
UP kernels and vice versa, and it does that well. But people
have gone one step too far and now use modversions to decide if
kernel ABIs have changed.
Alas modversions is not 100% accurate and anything less than 100%
accurate is asking for trouble when loading modules into kernels
with different configs. Modversions do not detect all the ABI
changes, e.g. there is no way to detect if spin lock debugging is
active or not in the ABI hash. Build a module with spin lock
debugging, load it into a kernel without spin lock debugging and
watch it oops, but according to modversions they are compatible.
Another problem with modversions is they rely on users manually
running make dep after config changes or applying patches. We
know that they do not do this, http://www.tux.org/lkml/#s8-8 gets
lots of references. The standard answer to modversion problems
is "delete everything and rebuild", how Microsoft is that?
The re-calculation of modversions can be automated (we know which
files export symbols) but that just brings us up against the next
problem. There is no way to tell which code consumes an exported
symbol. The only thing to do if _any_ module symbol version has
changed is to rebuild _all_ modules. Highly unsatisfactory.
Given all those problems, I have designed a safe method of
handling ABI detection for modules. That method runs at the back
end of a build instead of at the start, it is the only way to
keep the data up to date. It hooks nicely into kbuild 2.5 but
not the existing build system. For obvious reasons, I will not
start on the new modversion code until kbuild 2.5 is in and
stable. If kbuild 2.5 goes in then I will have a clean
modversions system before before kernel 2.5 becomes 2.6. If
kbuild 2.5 does not go in then we are stuck with the existing
broken modversions.
Q15. Why do we need a flag day?
A15. kbuild 2.5 can coexist with the existing build system but
eventually it must either die or replace the existing system.
Given the need for a new syntax to handle timestamps, separate
source and object trees, compiling third party source and the
change from recursive to non-recursive, there is no sensible way
to phase in the makefile changes. The conversion to the new
Makefile.in syntax must be global.
OTOH, there were 329 Makefile changes between 2.5.15 and 2.5.19
(i.e. all makefiles were changed), so why worry about one more?
Especially when this will be the last global change to makefiles
for kbuild.
Q16. Can kbuild 2.5 be split into separate patches?
A16. Not in any sensible way. It is already split into core, common
and arch code. There is no point in adding the core code without
the Makefile.in files from the common and arch patches, there is
nothing for the core code to work on. Adding the common and arch
patches without the core code to process them is equally
pointless.
There are some minor bug fixes to shared build code could be done
separately, some have already been submitted. However that does
nothing about my real problem - Linus does not want to look at
kbuild 2.5. The bug fixes have already been fed back to 2.4.
Some people have suggested splitting the asm-offset changes.
That ends up being more work, the clean Makefile.in rules for
asm-offset have to be retrofitted to the clumsy method used in
the existing system. Remember that these are a mixture of target
compiles and host commands, kbuild 2.5 supports that cleanly, the
existing system does not.
Q17. Can we do the changes in smaller steps?
A17. Once you accept the need for a new syntax, a database to handle
timestamps and dependencies correctly and the pre-processing
programs to do all the work, any further work on the existing
build system is a complete waste of time. Why fiddle with the
existing syntax and Rules.make when it will all be replaced?
Q18. What about tags/rpm/other miscellaneous targets?
A18. I have put my foot down on what goes into kernel build and what
does not go in. It is the job of kbuild to build and install the
kernel, it is not kbuild's job to run the packaging manager of
the day.
kbuild 2.5 provides an extensive infrastructure which can be used
by other scripts to perform additional processing that is not
related to the kernel build. This is another advantage of making
the install a fully supported target instead of a partial add on.
One of the install options is "run a post-install script", that
script gets all the install information and can do whatever the
user wants.
I do not object to Redhat, Debian, Slackware etc. supplying
sample scripts to run their packaging code, but these scripts
will not be permanently hooked into kbuild 2.5. Instead the user
can take a copy, modify as required then run the modified script
during install. No more tweaking the kernel install rules to do
something special for your system.
Tags, ctags, cscope etc. fall into the same category. These
targets will be converted to sample scripts which each user can
modify to suit their own requirements.
Q19. What about 2.4 kernels?
A19. Because kbuild 2.5 can coexist with the existing build system,
there is nothing to stop people using kbuild 2.5 on 2.4 kernels,
it was developed that way. Some people are already using kbuild
2.5 on 2.4 kernels for the reliability and speed.
There are no plans to replace the kernel build system in 2.4
kernels with kbuild 2.5. It is too big a change for a stable
kernel. Bug fixes from kbuild 2.5 have already been fed back to
the 2.4 build system.
Q20. Only one person understands kbuild 2.5.
A20. Pure FUD. Lots of people understand the Makefile.in syntax, I
get bug fixes all the time and multiple people have worked on the
arch specific patches. The kbuild 2.5 syntax is fully
documented, which is more than can be said for the existing
syntax.
There are only a few people who bother with the core code, but
that has always been true of the kernel build system. Only the
kbuild maintainers care what the core code does, everybody else
just writes build rules. The core code is fully documented,
complete with database design, notes on what the various flags do
and even a schema diagram.
Q21. The core patch is too big.
A21. Since when has code size mattered? Does that mean that
drivers/acpi should be removed? Or sound? Both are much bigger
than the kbuild 2.5 core patch.
You will also see people saying that kbuild 2.5 is "30,000 lines
of C code". This is more FUD from people who have not actually
looked at the patch. core-15 breaks down into
Lines Words Bytes
Documentation 8372 67342 300084
Generated C code (no need for yacc/lex) 5591 25514 169830
Makefiles (will replace existing files) 1678 8942 67906
Support scripts 219 1125 7374
Database engine 3139 13148 89169
Pre-processing code 9026 38059 239812
Those figures include the patch headers, so the real numbers are
even smaller.
It is the pre-processing code that does the real work - 9,000
lines of C, yacc and lex. And that includes lots of comments in
the code, in addition to the separate documentation files.
Q22. Are all the kbuild problems being fixed by Kai's work?
A22. No. Kai is cherry picking the easy fixes out of other people's
work but he is completely ignoring the big problems.
Kai has said that he will not support compilation for third party
code. kbuild 2.5 already does this.
Kai thinks he knows how to do non-recursive make, but no code has
appeared. kbuild 2.5 already does this.
Kai thinks he might be able to do separate source and object
trees but is not sure. kbuild 2.5 already does this.
Kai has not considered extracting the data that Rusty needs to
standardize the parameter handling for boot time and module load.
kbuild 2.5 already does this.
There is no way to solve the timestamp problem without radical
syntax changes and extra code to do all the checking. kbuild 2.5
already does this.
All Kai has done is duplicate the work I did months ago on the
makefile clean up. And BTW, introduced build errors while doing
so. The build errors that Kai introduced have been corrected in
kbuild 2.5.
Q23. Why rebuild the makefile every time?
A23. Phase1 has to run every time to find out if files have been added
or deleted. Before saying that phases 2, 3 and 4 can be
automatically skipped if "nothing has changed", contemplate the
difference between
export KBUILD_SRCTREE_000=...
export KBUILD_SRCTREE_010=...
make ...
and
export KBUILD_SRCTREE_000=...
make ...
Meditate upon the meaning of
make ... emu10k1-DEBUG=1
with respect to sound/oss/emu10k1/Makefile.in.
Then come up with a 100% safe algorithm to determine if phases 2,
3 and 4 can be skipped. If it is not 100% safe, it does not go
into kbuild 2.5.
Users who 'know' that nothing has changed can use
NO_MAKEFILE_GEN=1. Their decision, their responsibility.
Q24. Why not explain all this to Linus?
A24. I have tried, damn it!
I started with a presentation of kbuild 2.5 at the 2.5 Kernel
Developer's Conference. After that presentation I spoke to Linus
and he agreed that kbuild 2.5 would go into the kernel at the
start of the 2.5 cycle. When 2.5 was split off, I sent Linus
multiple mails saying that kbuild 2.5 Release 1.0 was ready. He
completely ignored those mails, except for one comment "we have
more important things to do, like bio".
I thought that Linus's agreement meant something, obviously it
does not.
After speeding up the core code, Release 2.0 was issued. More
mails to Linus over several weeks were ignored, except for a
brief note under another thread entirely.
"I'm hoping we can get there in small steps, rather than a big
traumatic merge. I'd love to just try to merge it piecemeal.
Especially as I don't find the existign system so broken."
Several private mails then followed before I got a response.
Linus gave private excuses which he has not repeated in public,
suffice it to say that those reasons do not hold up. I tried
explaining why the existing system is broken, but he ignored me.
Since then Linus has started taking patches from Kai, without
caring that they make no attempt at fixing the big problems. It
is infuriating that Linus's latest mail on the topic said
"Kai has already shown that he can merge with me easily"
I have done all the right steps, many times. The reason I cannot
merge with Linus is because he ignores my mails!
Linus does not think that kernel build is important. He knows
how to build a kernel and does not have to handle the bug reports
from people who get it wrong.
If you think that the bug fixes and new features in kbuild 2.5
are worthwhile then tell Linus. Otherwise live with all the bugs
of the existing system and miss the advanced features of kbuild
2.5.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE8+3YZi4UHNye0ZOoRAuQ4AKCGz2Li0hYtq5/QWdxrntMs+jGEAQCfUEj4
V23uljc1Bz3ZURYLYZRJGdM=
=R2/z
-----END PGP SIGNATURE-----
On Monday 03 June 2002 15:58, Keith Owens wrote:
> I regret having to do this but Linus has left me with no other options.
>
> [...]
>
> Then tell Linus that you want kbuild 2.5.
Err, Keith, time to calm down ;-)
Linus has already indicated his position, I guess you were busy writing
the post so you didn't notice:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102304528224527&w=2
Plus you've got helpers, how could the situation be better?
--
Daniel
Keith Owens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Content-Type: text/plain; charset=us-ascii
>
> I regret having to do this but Linus has left me with no other options.
Somehow I can't resist, but this sounds like the
devfs and RaiserFS story again:
- devfs claimed "It will solve all major/minor number problems".
Well we still struggle to get over with them. But now we have to
account for the intricacies of devfs in addition too.
- RaiserFS "Trees rule the world".
Well ext3 (no I don't care about inn server!) is faster
XFS is better manegeable. The "mutable filesystem semantics" modules
and what a not are nowehre in sight.
Both projects which got included due to "public preasure".
On Mon, 3 Jun 2002, Keith Owens wrote:
> I regret having to do this but Linus has left me with no other options.
Keith: You're becoming even more stubborn and blinded than ESR was.
Linus became interested in kbuild-2.5 when someone else than you decided to
feed him with small patches, exactly what I told you a while ago and what
you called a "stupid comment".
Shame on you Keith.
Resisting the widely known Linus procedure will lead you nowhere, whether it
looks stupid or not to you.
Nicolas
> Somehow I can't resist, but this sounds like the
> devfs and RaiserFS story again:
>
> - devfs claimed "It will solve all major/minor number problems".
> Well we still struggle to get over with them. But now we have to
> account for the intricacies of devfs in addition too.
>
> - RaiserFS "Trees rule the world".
> Well ext3 (no I don't care about inn server!) is faster
> XFS is better manegeable. The "mutable filesystem semantics" modules
> and what a not are nowehre in sight.
>
> Both projects which got included due to "public preasure".
With all respect, Martin, if you want to offend Keith Owens, you'd be
better off trying to find _real flaws_ in kbuild25, rather than raking
the old muck about devfs.
Please reread Keith's post and try to understand what "the kbuild25
problem" is about. For if there's one issue it's NOT about, it's the
system's incompetence or redundancy.
Another one, in trying to put down other people's work, you should prolly
at least take care to spell names correctly. And FYI, reiserfs has been
here as a real solution for over two years and has worked perfectly, unlike
certain other code. I'm getting sick of this macho attitude from someone
who throws shit at *others* while unable to get *their own* work done
properly.
T.
On Monday 03 June 2002 15:58, Keith Owens wrote:
> Q07. Why is [b]zImage part of the config?
> A07. In the current system, installation is a poor relation of the
> build system. Each architecture has their own install targets
> with their own special rules. None of the install targets check
> that what is being installed was built correctly.
>
> In kbuild 2.5 the install target is a fully supported part of the
> build. Not only is [b]zImage (and all the other targets) part of
> the config, the config also supports installation to somewhere
> other than /, plus optional rules for installing the config and
> System.map at the same time as the kernel and modules. This
> significantly improves support for cross compilation.
>
> A nice side effect of putting all the install information in
> .config is that building a new kernel is as simple as
>
> cp previous_config .config
> make ... defconfig installable && sudo make install
That simplification is appreciated, but I think that
make -f Makefile-2.5 bzImage
should still be allowed, call it compatibility glue if you like.
For what it's worth, I find it quite natural to have the build
information in the .config and I was able to find my way to it
without reading the docs. Still - when Makefile-2.5 becomes just
plain Makefile, a lot of fingers are still going to want to type
"make bzImage".
--
Daniel
Nicolas Pitre wrote:
> On Mon, 3 Jun 2002, Keith Owens wrote:
>
>
>>I regret having to do this but Linus has left me with no other options.
>>
>
> Keith: You're becoming even more stubborn and blinded than ESR was.
>
> Linus became interested in kbuild-2.5 when someone else than you decided to
> feed him with small patches, exactly what I told you a while ago and what
> you called a "stupid comment".
>
> Shame on you Keith.
>
> Resisting the widely known Linus procedure will lead you nowhere, whether it
> looks stupid or not to you.
>
>
Why are you posting that on a mailing list?
Is that the attitude: I knew it beforehand? I told you so?
Please: not yet another flame war.
And you and Daniel are right: kbuild seems already on its way
(with help of Kai).
So what?
Keith: keep up the good work (and better deal with Linus :), thank you
Keith Owens <[email protected]> wrote:
<snip>
>Then tell Linus that you want kbuild 2.5.
>
>Don't tell me, I already know. Tell Linus, he is the bottleneck.
<snip>
>It is a sad day when a fully tested and documented system that is
>faster and, above all, more accurate, cannot get into the kernel.
>Linus is judging kbuild 2.5 on its popularity and on personalities, not
>on its technical merits.
<snip>
>I thought that Linus's agreement meant something, obviously it
>does not.
<snip>
Right, make Linus do what you want by impugning his technical judgment, calling
him a liar, and asking people to flood his mailbox with complaints. Sure, THAT
will work.
On Mon, 3 Jun 2002, Peter W?chtler wrote:
> Why are you posting that on a mailing list?
> Is that the attitude: I knew it beforehand? I told you so?
If that's the only thing you could grasp from what I wrote then I'm sorry
for you.
> Keith: keep up the good work (and better deal with Linus :), thank you
Keith is certainly doing excellent work, no doubt. Unfortunately he just
showed how inapt he is to deal with Linus.
Nicolas
On Mon, Jun 03, 2002 at 10:29:10AM -0500, [email protected] wrote:
> Keith Owens <[email protected]> wrote:
> >It is a sad day when a fully tested and documented system that is
> >faster and, above all, more accurate, cannot get into the kernel.
> >Linus is judging kbuild 2.5 on its popularity and on personalities, not
> >on its technical merits.
> Right, make Linus do what you want by impugning his technical
> judgment, calling him a liar, and asking people to flood his mailbox
> with complaints. Sure, THAT will work.
It is still unfortunate that all contributions, especially larger scale
ones, cannot be openly accepted and embraced. It isn't as if the change
is overly invasive... if both system can operate in parallel, the impact
is significantly less.
Alas, we have these things called precidents and processes that attempt to
hone the quality of releases at the cost of potential productivity.
Keith: I do not think Linus is discouraging kbuild 2.5 due to popularity
or personalities. I suspect he is discouraging it due to a healthy fear
of the precident that it would set, as well as the chance that it would
require a great deal more work and you and your collaborators all get hit
by a bus ( or get a life? :-) ) tomorrow morning.
I'm not certain where the line is for 'breaking the change up', such that
the effort does not become substantially more, but the requirement for the
line has been decreed.
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Hi,
On Mon, 3 Jun 2002, Mark Mielke wrote:
> I suspect he is discouraging it due to a healthy fear of the precident
> that it would set, as well as the chance that it would require a great
> deal more work and you and your collaborators all get hit by a bus ( or
> get a life? :-) ) tomorrow morning.
I didn't yet die, and it isn't planned for the next years. I won't die as
long as it's not implemented for me.
There are far more people who can speak kbuild-2.5 (or get into it) in the
world than busses. I suspect that even after the worst, life goes on! And
even Aunt Tillie could maintain kbuild-2.5....
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Mon, Jun 03, 2002 at 11:58:51PM +1000, Keith Owens wrote:
> I regret having to do this but Linus has left me with no other options.
What about the "collaborate with Kai" option?
OG.
> And you and Daniel are right: kbuild seems already on its way
> (with help of Kai).
now my/the questions are:
- is what Kai is doing really leading to kbuild2.5
- how man iterations will it take, will it be ready for 2.6 (whenenvwer
that is).
- at what point will the kbuild-users have to learn new tricks, where is
the point of no-return?
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
Hi,
On Mon, 3 Jun 2002, Martin.Knoblauch wrote:
> now my/the questions are:
>
> - is what Kai is doing really leading to kbuild2.5
Not necessarily (Yet, it doesn't. It's just a plug of what was _indeed_
corrected directly the like in kbuild-2.5.) But yet I'm confident we'll
get that done, but we all (even Kai) will have to change our attitudes.
However, I don't have prejudices for Kai, and I will try my best to get my
work done.
> - how man iterations will it take, will it be ready for 2.6 (whenenvwer
> that is).
If it goes on the like it did for now, you'd better wait for linux-2.8. I
don't think it will get in like this.
> - at what point will the kbuild-users have to learn new tricks, where is
> the point of no-return?
The moment we merge Makefile-2.5 and Makefile, discarding compatibility
targets.
However, try my linux-2.5.20-ct1, scheduled for somewhen until Wednesday.
You can get a clear insight on some things such as kbuild-2.5 then.
> Martin
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Mon, 2002-06-03 at 09:15, Daniel Phillips wrote:
> On Monday 03 June 2002 15:58, Keith Owens wrote:
> > I regret having to do this but Linus has left me with no other options.
> >
> > [...]
> >
> > Then tell Linus that you want kbuild 2.5.
>
> Err, Keith, time to calm down ;-)
Agreed. I may be a newbie on *this* list, but not to lists in general.
Keith, I wholly respect all the work you've done as it *is* a good thing
and certainly a large step in the right direction, as all the numbers
clearly prove.(I say that because I'm certain that anyone else doing the
same testing would find the same things..so have at it!)
But impatience is seldom rewarded the way we'd often like. Something I
myself must remember, often!
Linus didn't lie, remember that, he even stated his position, as listed
below. Patience is key, but so is proper communication of intent. (see
below)
> Linus has already indicated his position, I guess you were busy writing
> the post so you didn't notice:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=102304528224527&w=2
>
> Plus you've got helpers, how could the situation be better?
To play devil's advocate for just a minute: It would seem that
impatience is a two way street. Linus has decided how it should work,
and as we all know, this is a similar situation to CML2(ESR).
The thing which remains constant however is a lack of communication
around timing. Without that information, from either party in this
discussion:Keith and Linus for all intents, then it often will be ill
rewarded for both parties.
This is how flame wars seem to escalate rapidly and nearly every time,
about something which multiple parties believe is important.
Let us take a step back, or completely off-line this discussion for a
day or two, and then have at it again, if the list permits.
We should know that kbuild 2.5 is looked at by Linus and Kai. Let us not
*trash* another great make system. Let us take time and understanding,
but without the clear and crisp communication of intentions, timing
included, then it usually makes things *far* more frustrating than they
should've been.
> --
> Daniel
> -
> 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/
It'd be easier if Linus would say now:
"KEITH, I'LL MERGE KBUILD 2.5"
but he must have some reason. Perhaps I don't understand it because I
haven't to make happy to such mass of people ;)
On Tue, 4 Jun 2002 00:10:05 +0200, Diego Calleja <[email protected]>
wrote:
>It'd be easier if Linus would say now:
>
>"KEITH, I'LL MERGE KBUILD 2.5"
>
>
>but he must have some reason. Perhaps I don't understand it because I
>haven't to make happy to such mass of people ;)
Linus is doing things in his style. He has chosen a trusted lieutenant
(Kai) who is not a committed "true believer". Kai will work through
kbuild 2.5 and feed it to Linus in small batches. Keith will (should)
work with Kai. Thus a delegation and filtering step so Linus doesn't
have to understand every aspect of the change. Kai has done it before
(ISDN code) and Linus trusts him.
Management 101...
john alvord
Hi,
On Tue, 4 Jun 2002, Diego Calleja wrote:
> "KEITH, I'LL MERGE KBUILD 2.5"
I'm currently on it! Please don't cry out so badly.
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
oh, i must have swritten badly!. I only wanted to say that it'd be nice
sometimes to hear a few words from linus, so we doesn't have to wait to
read the chagelogs to see if a thing was included ;)
On Tuesday 04 June 2002 00:10, Diego Calleja wrote:
> It'd be easier if Linus would say now:
>
> "KEITH, I'LL MERGE KBUILD 2.5"
Linus doesn't do that, and I still love him.
--
Daniel
>>
>>"KEITH, I'LL MERGE KBUILD 2.5"
>>
>>
>>but he must have some reason. Perhaps I don't understand it because I
>>haven't to make happy to such mass of people ;)
>
>
>Linus is doing things in his style. He has chosen a trusted lieutenant
>(Kai) who is not a committed "true believer". Kai will work through
>kbuild 2.5 and feed it to Linus in small batches. Keith will (should)
>work with Kai. Thus a delegation and filtering step so Linus doesn't
>have to understand every aspect of the change. Kai has done it before
>(ISDN code) and Linus trusts him.
>
>
>Management 101...
Basically correct with two "but"s. It seems that Linus has only very
recently stated that Kai should do the work. And apparently he did not
tell Keith very clearly how to to proceed. Also, from the qouted link:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102304528224527&w=2
it is not clear to me whether this will lead to kbuild-2.5 "(or whatever
subset of them you find appropriate)". So I have some sympathy for Keith
for being impatient and worried about "his" project. Maybe things would
calm down if Kai could state his intentions and timetable?
While delegation of authorithy is of course Managment 101, lack of clear
communication is probably in the same book - high on the "NONO" and
"popular reasons for failure" lists. (Have some experience on that. From
both sides :-(
And the whole community is still eagerly waiting for the timetable (as
someone else already pointed out). I don't really care how it is done, as
long as it is done at all and we get the 2.5 benefits before 2010 (no,
that was for IDE :-).
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
[email protected] (Daniel Phillips) wrote on 03.06.02 in <E17Esc6-0000v9-00@starship>:
> Linus has already indicated his position, I guess you were busy writing
> the post so you didn't notice:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=102304528224527&w=2
>
> Plus you've got helpers, how could the situation be better?
I fail to see how this is supposed to work, and I guess so does Keith.
Kai (a different Kai!) does not seem to want to integrate the core part of
kbuild2.5. He seems to want to only pick the low-hanging fruits and make
unsupported (and unbelievable) noises about the rest.
And Linus seems to want to ignore the fact that the core portion of
kbuild2.5 is, by its very nature, not something that can be merged
"gradually" - just like ALSA, or a new architecture, can't meaningfully be
merged "gradually". (And he *also* said that he wasn't interested in
pseudo-gradually, i.e. getting the stuff in parts but still making a big
exchange.)
Frankly, I see *absolutely no way* how the current Kai-Linus "merge" can
possibly end with something even remotely like Keith's kbuild2.5. Unless
Linus changes his approach radically.
If I were Keith, I'd be rather upset, too.
MfG Kai
On Thu, Jun 06, 2002 at 09:31:00PM +0200, Kai Henningsen wrote:
> Frankly, I see *absolutely no way* how the current Kai-Linus "merge" can
> possibly end with something even remotely like Keith's kbuild2.5. Unless
> Linus changes his approach radically.
>
> If I were Keith, I'd be rather upset, too.
And beating ones head against the Linus-wall tends to end up with you
having a sore head in the end.
Either Kai will fix everything and not use kbuild-2.5 from keith (which
would be a shame) or eventually decide to use Keiths work. And little
to nothing apart from time will give us one of the two solutions.
And FWIW, I like kbuild-2.5.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
[email protected] (Kai Henningsen):
>
> [email protected] (Daniel Phillips) wrote on 03.06.02 in <E17Esc6-0000v9-00@starship>:
>
> > Linus has already indicated his position, I guess you were busy writing
> > the post so you didn't notice:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=102304528224527&w=2
> >
> > Plus you've got helpers, how could the situation be better?
>
> I fail to see how this is supposed to work, and I guess so does Keith.
>
> Kai (a different Kai!) does not seem to want to integrate the core part of
> kbuild2.5. He seems to want to only pick the low-hanging fruits and make
> unsupported (and unbelievable) noises about the rest.
>
> And Linus seems to want to ignore the fact that the core portion of
> kbuild2.5 is, by its very nature, not something that can be merged
> "gradually" - just like ALSA, or a new architecture, can't meaningfully be
> merged "gradually". (And he *also* said that he wasn't interested in
> pseudo-gradually, i.e. getting the stuff in parts but still making a big
> exchange.)
>
> Frankly, I see *absolutely no way* how the current Kai-Linus "merge" can
> possibly end with something even remotely like Keith's kbuild2.5. Unless
> Linus changes his approach radically.
>
> If I were Keith, I'd be rather upset, too.
How about the following approach, which MAY not be practical:
1. Name all of the new Makefiles Makefile.k2.5
2. Create a small wrapper script to define make as "make -f Makefile.k2.5"
or just define MAKE as make -f Makefile.k2.5 in the top level Makefile.k2.5
Put the kbuild2.5 specific tools in a directory reserved for kbuild2.5
tools.
This should allow both build procedures to reside side by side. Use one
or the other, but don't mix them (don't build the kernel using one,
then build the modules using the other, though that MIGHT work, it doesn't
have to). It may be necessary to have disjoint configure file names.
To switch between them should take a "make clean", then rename the wrapper
script. Dependant tools should reside in different directories to prevent
name collision. Common tools wouldn't change.
After everyone is happy with the new build procedures, the older one
could be retired. A clean-up patch could then rename the Makefiles and
fix any final targets, though I would favor just leaving that the same
as a pattern for future kbuild evoultion/revolution.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
> How about the following approach, which MAY not be practical:
Please note that there have already been innumerable proposals of
how to merge kbuild 2.5, and all of them have been silently rejected.
What I keep pondering over is, what is it that Linus finds troublesome
about merging the whole of kbuild 2.5? More -- why has he decided to
keep this to himself? Something tells me the answer to these questions
might be the key to solving the whole kb25 merge problem.
Hmmmm, it's rather odd to have to write about someone in 3rd person
when you know they'll read the text; They'll even give it a bit of
thought and will likely have things to say. They won't let you know,
though. You've noticed Linus was a he in the "if you want kbuild 2.5,
tell Linus" mail, haven't you? If I was a psychologist, I might have
something interesting to say based on that information. :)
Oh well.
And as for your idea, I'd say it really is impractical. kbuild 2.5
can live in perfect peace with the old build system as it is.
T.
On Thursday 06 June 2002 21:31, Kai Henningsen wrote:
> [email protected] (Daniel Phillips) wrote on 03.06.02 in <E17Esc6-0000v9-00@starship>:
>
> > Linus has already indicated his position, I guess you were busy writing
> > the post so you didn't notice:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=102304528224527&w=2
> >
> > Plus you've got helpers, how could the situation be better?
>
> I fail to see how this is supposed to work, and I guess so does Keith.
>
> Kai (a different Kai!) does not seem to want to integrate the core part of
> kbuild2.5. He seems to want to only pick the low-hanging fruits and make
> unsupported (and unbelievable) noises about the rest.
There's certainly been time enough for action, and I don't see any. I'd
say Kai (the other Kai) is stalling and not being cooperative at all.
--
Daniel
On Thu, Jun 06, 2002 at 04:01:27PM -0500, Jesse Pollard wrote:
> [email protected] (Kai Henningsen):
> > Frankly, I see *absolutely no way* how the current Kai-Linus "merge" can
> > possibly end with something even remotely like Keith's kbuild2.5. Unless
> > Linus changes his approach radically.
> > If I were Keith, I'd be rather upset, too.
> How about the following approach, which MAY not be practical:
> 1. Name all of the new Makefiles Makefile.k2.5
> 2. Create a small wrapper script to define make as "make -f Makefile.k2.5"
> or just define MAKE as make -f Makefile.k2.5 in the top level
> Makefile.k2.5
I think if you had read their posts more thoroughly, or checked the patch
out yourself, you would have found that they already did this.
kbuild2.5 and kbuild2.4 are already made to exist side by side.
I dunno about the Linus-wall thing though. I think Linus has good reasons
that apply in the general case, but probably don't apply at all for this
specific case.
How do you make an exception without allowing for exceptions?
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Hi,
On 6 Jun 2002, Kai Henningsen wrote:
> Frankly, I see *absolutely no way* how the current Kai-Linus "merge" can
> possibly end with something even remotely like Keith's kbuild2.5. Unless
> Linus changes his approach radically.
At least there are some trees which already include it. Maybe there will
be some more people using kbuild-2.5 in their trees within a few
weeks/monthes, and maybe one day - may not be today, may not be tomorrow -
but one day it will get into the common tree.
> If I were Keith, I'd be rather upset, too.
Anyway, he shouldn't be. There are lots of people appreciating his work,
and many of us are very grateful for it. So am I. It's going to be a long
way, but finally kbuild-2.4 can't stand while kbuild-2.5 (hopefully) goes
on. So we'll get it in by some time in the future.
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
Hi,
On Thu, 6 Jun 2002, Jesse Pollard wrote:
> How about the following approach, which MAY not be practical:
Yepp, it's so incredibly practical that it's already in (the name is
Makefile-2.5, and I got a little script called kbuild which does
make -f Makefile-2.5 $@ for me.)
Get used to it, and try the patch!
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
[email protected] said:
> and I got a little script called kbuild which does make -f
> Makefile-2.5 $@ for me.)
Something wrong with 'echo include Makefile-2.5 > GNUmakefile' ?
--
dwmw2
Hi,
On Sat, 8 Jun 2002, David Woodhouse wrote:
> Something wrong with 'echo include Makefile-2.5 > GNUmakefile' ?
In theory, no. In theory. I can't check it for now, do you see anything
wrong with it?
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Thu, 6 Jun 2002, Tomas Szepe wrote:
> > How about the following approach, which MAY not be practical:
>
> Please note that there have already been innumerable proposals of
> how to merge kbuild 2.5, and all of them have been silently rejected.
>
> What I keep pondering over is, what is it that Linus finds troublesome
> about merging the whole of kbuild 2.5? More -- why has he decided to
> keep this to himself? Something tells me the answer to these questions
> might be the key to solving the whole kb25 merge problem.
As I see the problem, the proposal has been either rejected or
postponed, and some people refuse to accept that. I would love to see the
best of O1 and preempt in 2.4, too, but I'm not going to ask anyone to
write Linus, or Marcel, or Sen. Hollings and tell them my idea is a good
idea. As long as patches are available and I'm able to apply them, I will
grumble under my breath and move on. That's my vote for a solution to the
kb25 merge problem, accept that a decision has been made and move on.
> Hmmmm, it's rather odd to have to write about someone in 3rd person
> when you know they'll read the text; They'll even give it a bit of
> thought and will likely have things to say. They won't let you know,
> though. You've noticed Linus was a he in the "if you want kbuild 2.5,
> tell Linus" mail, haven't you? If I was a psychologist, I might have
> something interesting to say based on that information. :)
I spent half of the weekend with a small child who asked his other to
let him do something. His mother said no, and instead of doing any of the
other things available to him, the spent the afternoon, evening, and
following morning asking his siblings, aunts and uncles, and grandparents
to tell his mother why he should be allowed to do that particular thing.
As a result he wasted his time, didn't do anything fun in that time, and
pissed off his mother to no end.
I shouldn't wonder if Linus hasn't heard all he wants on this, he is
certainly willing to enter a dialong when he feels discussion is useful.
if I were pushing this change I might read something into that and not
flagellate this particular deceased equine.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.