Announce: Kernel Build for 2.5, release 3.0 is available

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download release 3.0.

kbuild-2.5-core-15
Changes from core-14.

Replace mdbm with kbuild specific database engine to increase performance.

Remove CML2 support, Dominik Brodowski, Keith Owens.

Remove the restriction on symlinked sources and targets. Aegis users should be able to use kbuild 2.5 now.

kbuild-2.5-common-2.5.19-1.
Changes from common-2.5.15-4.

    Upgrade to kernel 2.5.19.

kbuild-2.5-i386-2.5.19-1.
Changes from i386-2.5.15-2.

    Upgrade to kernel 2.5.19.

Larry McVoy provided the mdbm database engine from BitKeeper for use in kbuild 2.5 release 2.0-2.4, and was extremely helpful in answering my questions about mdbm. Unfortunately some of the processing required by kbuild 2.5 did not fit well with the mdbm model. Since an application specific database will always outperform a generic database, I took advantage of knowledge about the kbuild data and wrote an application specific database engine.

This is not a criticism of mdbm - it is a good generic database engine. I could squeeze a few more seconds out of the build time by using application specific knowledge.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE8+tXYi4UHNye0ZOoRAp+5AJ9evi07/7D1+xHRRnxA8xdpeqY3hgCeMcrH kgNAIKaGHE1Fy8BKByBZqXs=
=EamL
-----END PGP SIGNATURE-----

Added kbuild-2.5-common-2.5.20-1 and kbuild-2.5-i386-2.5.20-1, upgrade to 2.5.20. No core changes.

I get this error now on sparc64:

tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
  phase 1 (find all inputs)
make: *** [phase1] Error 139

tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
  phase 1 (find all inputs)
pp_makefile1: Attempt to fetch invalid key s(0x73)-9473
make: *** [phase1] Error 134

more verbose (PP_MAKEFILE1_FLAGS=-v) output:

...
Generating global Makefile
phase 1 (find all inputs)
pp_makefile1 verbose 1
scan_trees 0 /build2/tduffy/linux_kbuild/
make: *** [phase1] Error 139

-tduffy

Hi,

Did you apply the sparc64 patch? Yet it's there.

You might even try the upcoming -ct1

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

yes.

this is failing in the db code, my guess.

ok, I will give it a go, but I think this is a problem in core-15 (kbuild v3.0)

-tduffy

Hi,

Gee, you're right!

Could you please try the core-14 beforehand? (Yes, beat me, Keith, but if it works, we'll have a stepping stone!)

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

<= core-14 works fine...

-tduffy

Index: 18.85/scripts/pp_db.c

@@ -305,7 +305,7 @@ ppdb_free_space(PPDB * db, int size)
 	}
 	oldmap = db->header;
 	ppdb_close(db);
-	if (munmap(db->header, oldsize)) {
+	if (munmap(oldmap, oldsize)) {
 		fprintf(stderr, "%s: munmap(%s) failed: %m\n", program,
 			ppdb_name);
 		abort();

The previous coding error will have corrupted the database so rm .tmp_db_main.

awesome. that fixes the problem. thanks.

-tduffy

New files:

kbuild-2.5-core-16
Changes from core-15.

Override some command line variables to ensure that they are changed.

Replace -nostdinc with Russell King's version.

Print full filename in warning message.

Correct lock filename.

Correct unmap old db (sparc64 SEGV).

Tweak dirty flag checking.

kbuild-2.5-common-2.5.20-2.
Changes from common-2.5.20-1.

Correct drivers/acpi/Makefile.in, Arnd Bergmann.

kbuild-2.5-s390-2.5.20-1.
kbuild-2.5-s390x-2.5.20-1.

Arnd Bergmann.

I still have a link order problem in -common-2.5.20-[12] that I noticed after I eventually tried to run my kbuild-2.5 kernel.

The initialization code in arch/i386/pci needs the pci_bus_type object from drivers/pci/pci-driver.c to be registered. Both is called at subsys_initcall level, but in kbuild-2.5 the arch specific parts are run first. The symtom is a 'BUG in device.h:75' from get_bus() early in bootup.

The brute force workaround for this problem is to put link_subdir(drivers/pci) before link_subdir(arch/$ARCH) in the top level Makefile.in.

I could not find out from the kbuild-2.4 files how or why it works there, but I don't think relying on the link order here is a good idea anyway, so it would best be fixed in the pci code itself.

Arnd <><

New files:

kbuild-2.5-core-17
kbuild-2.5-common-2.5.20-3
kbuild-2.5-i386-2.5.20-2

Synchronize link order with 2.5.20. Between 2.5.15 and 2.5.19 there were several changes to the kernel link order that look dubious to me. Originally kbuild 2.5 for 2.5.20 preserved the original order from 2.5.15, but I have since decided to follow the 2.5.20 link order, even if it looks broken in places.

common-2.5.20-3 also adds workarounds for include/linux/zlib.h.

New files:

kbuild-2.5-core-18
Change from core-17.

Add a missing case for dependency standardization.

kbuild-2.5-common-2.4.18-8
kbuild-2.5-i386-2.4.18-3

Synchronize link order method with 2.5.20, so both 2.4 and 2.5 versions of kbuild 2.5 use the same process.

kbuild-2.5-common-2.4.19-pre10-1
kbuild-2.5-i386-2.4.19-pre10-1

Upgrade to 2.4.19-pre10. Also has new link order method.

New files:

kbuild-2.5-core-19
Change from core-18.

Change allno/allyes/allmod to all*config.
Replace $([<^@][DF]) with $(dir/notdir).
Do a dummy write to the database to workaround a kernel bug on timestamps of mmaped files.

kbuild-2.5-i386-2.4.18-4
kbuild-2.5-i386-2.4.19-pre10-2

Backport CC/CC_real fix from 2.5.

kbuild-2.5-common-2.5.21-1
kbuild-2.5-i386-2.5.21-1

    Upgrade to 2.5.21.

More arch patches for 2.5.21 to follow.

hrm. I don't see any of these on the sourceforge site...

Are they really missing, or am I an idiot?

-tduffy

I got side tracked and did not complete the upload. They are there now.

Got this trying to compile 2.5.20 with Debian's gcc 2.95.4. Why it took the system-wide zlib.h?

$ make -f Makefile-2.5 fs/isofs/compress.o KBUILD_QUIET=
...
scripts/pp_makefile5  --type=CC --target=fs/isofs/compress.o --src=fs/isofs/compress.c --srctree=999 --flags='-Ifs/isofs -I- -D__KERNEL__ -Iinclude/ -I.tmp_include/src_000/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2    -fomit-frame-pointer -march=i686 -nostdinc -iwithprefix include  -DKBUILD_OBJECT=isofs -DKBUILD_BASENAME=compress -DMODULE   '
In file included from /export/home/riesen-pc0/riesen/compile/v2.5/fs/isofs/compress.c:38:
include/linux/zlib.h:34: zconf.h: No such file or directory

In order to do separate source and object correctly, kbuild 2.5 enforces the rule that #include "" comes from the local directory, #include <> comes from the include path. include/linux/zlib.h incorrectly does #include "zconf.h" instead of #include <linux/zconf.h>, breaking the rules.

This was not detected by common-2.5.20-1 because the nostdinc check was incomplete, common-2.5.20-2 does nostdinc correctly. I avoid changing the source code for kbuild 2.5, instead I workaround these incorrect includes by adding extra_cflags() with FIXME comments to correct the code later. I will do a common-2.5.20-3 to workaround zlib.h, in the meantime try this quick and dirty fix

@@ -31,7 +31,7 @@
 #ifndef _ZLIB_H
 #define _ZLIB_H
 
-#include "zconf.h"
+#include <linux/zconf.h>
 
 #ifdef __cplusplus
 extern "C" {

Keith Owens scripsit:

This is not the standard gcc behavior, however; quoted-includes can come from the include path, although the current directory is searched first. The purpose of <>-includes is to suppress searching the current directory.

John Cowan <[email protected]>     http://www.reutershealth.com
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, _LOTR:FOTR_

What gcc allows and what the kernel uses as a coding style are two different things. Almost all of the kernel uses <> for global files and "" for local files, this is the only sane way of coding for a large project. However there are some exceptions where the wrong form has been used.

The wrong form causes problems for separate source and object directories. It also causes problems when you do not compile in the same directory that does not contain the source, i.e. when you do a global make instead of recursive make. kbuild 2.5 has identified all of the problem includes. I avoided changing the source, instead I added extra include paths as a temporary workaround, with FIXME comments for later clean up. I noticed that some people have already used the kbuild 2.5 FIXME comments to clean up their code.

It raises the question 'who not always use #include "..."'?

In the case of a tool that generates dependencies for a source file, the difference is sensibility.

In other cases, it is just common sense.

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/

Sorry for delay. The patch fixed things, indeed.
And i personally prefer the way you did it here
much more to any workarounds.