kbuild: possible regression?

From: Jan Altenberg
Date: Wed Oct 31 2007 - 05:04:21 EST


Hi all,

I'm not quite sure if this might be a regression, but I recognized a
change to kbuild's behaviour, which causes some of my build scripts to
fail.

The build scripts do:

return system(('make -C %s O=%s ARCH=%s CROSS_COMPILE=%s '+
'oldconfig %s %s < /dev/null || exit %i') %
(srcdir,
builddir,
arch,
crosscompile,
target,
modules_target,
FAILED_RETCODE))

which results in something like:

make -C /here/workdir/linux-2.6/common/src O=/here/workdir/linux-2.6/common/build/build \
ARCH=i386 CROSS_COMPILE=/opt/i686-linux/bin/i686-linux- \
oldconfig bzImage < /dev/null || exit 1

In the past, oldconfig was the first target, which has been handled.

Now, bzImage seems to get handled at first. That causes my build scripts
to fail, because the bzImage target does a silentoldconfig, which
doesn't allow console redirection.

[...]

Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [14] 14
Control Group support (CGROUPS) [N/y/?] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update configuration.

make[5]: *** [silentoldconfig] Error 1
make[4]: *** [silentoldconfig] Error 2
make[3]: *** [include/config/auto.conf] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [/here/workdir/linux-2.6/common/src/scripts/Kbuild.include] Error 2
make: *** [sub-make] Error 2
make: Leaving directory `/here/workdir/linux-2.6/common/src'

[...]

After silentoldconfig has failed, oldconfig seems to get executed and
after that the bzImage build is starting. So far so good, BUT: My script
checks the return value and fails after the execution of
silentoldconfig. That's why I recognized the different behaviour.

I did a git bisect to identify the commit, which caused the change to
kbuild's behaviour. The offending commit is:

commit 0b35786d77ba4037f181982cc8ca20a7a3bf0fd2
Author: Milton Miller <miltonm@xxxxxxx>
Date: Fri Sep 21 18:09:02 2007 -0500

kbuild: call make once for all targets when O=.. is used

Change the invocations of make in the output directory Makefile and the
main Makefile for separate object trees to pass all goals to one $(MAKE)
via a new phony target "sub-make" and the existing target _all.

When compiling with separate object directories, a separate make is called
in the context of another directory (from the output directory the main
Makefile is called, the Makefile is then restarted with current directory
set to the object tree). Before this patch, when multiple make command
goals are specified, each target results in a separate make invocation.
With make -j, these invocations may run in parallel, resulting in multiple
commands running in the same directory clobbering each others results.

I did not try to address make -j for mixed dot-config and no-dot-config
targets. Because the order does matter, a solution was not obvious.
Perhaps a simple check for MAKEFLAGS having -j and refusing to run would
be appropriate.

Signed-off-by: Milton Miller <miltonm@xxxxxxx>
Signed-off-by: Sam Ravnborg <sam@xxxxxxxxxxxx>

So, am I facing a kbuild regression?

Cheers,
Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/