2007-09-16 09:46:24

by Sam Ravnborg

[permalink] [raw]
Subject: kbuild update

A summary of what is planned to be submitted in next merge window for kbuild.
The shortlog below have additional details but the headlines are:

o Make the kernel buildable on a cygwin box (but not without a few glitches)
o detect unterminated device id list
o add export_report as a valid top-level make target
o add script to find unused kconfig symbols (try it!)
o allow a user to specify additional flags on the commandline with
CFLAGS, AFLAGS or CPPFLAGS. The flags will be appended to the kernel defiend flags

The CFLAGS change will conflict with Andi's x86 patches and I fix it
before pushing if Andi's patches are pushed first.
Otherwise no conflicts.

The vmlinux.lds changes that I have sent to a number of arch maintainers
lately are not included.
I expect them to be applied by the respective arch maintainers.

The --gc-section cleanup from Denys Vlasenko will be included in
kbuild after the merge window so we can try it out in -mm before
hitting mainline.

Jan Beulich kconfig patch will most likely be included.
Need to test it first.

Marej menuconfig improvement may also be included.
Last patch looked good but have not made up my mind if it
really help people.

Patched referred below are available at git.kernel.org at kbuild.git
in an hour or so.

Sam


Adrian Bunk (2):
kbuild: fix export_report.pl
kbuild: call export_report from the Makefile

Jesper Juhl (3):
kbuild: improve scripts/gcc-version.sh output a bit when called without args
kbuild: ver_linux fix glibc version print
kbuild: scripts/ver_linux : correct printing of binutils version

Kees Cook (1):
kbuild: make modpost detect unterminated device id lists

Mike Frysinger (1):
kbuild: clean Modules.symvers in external module dirs

Paolo 'Blaisorblade' Giarrusso (1):
kbuild: script to check for undefined Kconfig symbols

Petr Stetiar (1):
kbuild: fix segfault in modpost

Ram Pai (1):
kbuild: fix perl usage in export_report.pl

Randy Dunlap (1):
docproc: style & typo cleanups

Sam Ravnborg (10):
kbuild: Use Elfnn_Half as replacement for Elfnn_Section
kbuild: check if we can link gettext not just compile
kbuild: fix genksyms Makefile
kbuild: __extension__ support in genksyms (fix unknown CRC warning)
kbuild: apply genksyms changes
kbuild: enable 'make CFLAGS=...' to add additional options to CC
kbuild: enable 'make AFLAGS=...' to add additional options to AS
ia64: fix sn to add include files using EXTRA_CFLAGS
kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP
kbuild: fix directory traversal bug

Shlomi Fish (1):
kconfig: qconf ("make xconfig") Search Dialog Enhancement


2007-09-16 13:00:17

by Robert P. J. Day

[permalink] [raw]
Subject: Re: kbuild update

On Sun, 16 Sep 2007, Sam Ravnborg wrote:

> A summary of what is planned to be submitted in next merge window for kbuild.
> The shortlog below have additional details but the headlines are:
...
> o add script to find unused kconfig symbols (try it!)

based on my experiences with this, unless you filter carefully, you're
going to end up with a *whack* of false positives given the number of
developers who elect to name their local macros starting with a prefix
of "CONFIG_". good luck dealing with *that*. :-)

rday

--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

2007-09-16 15:11:58

by Sam Ravnborg

[permalink] [raw]
Subject: Re: kbuild update

On Sun, Sep 16, 2007 at 08:58:03AM -0400, Robert P. J. Day wrote:
> On Sun, 16 Sep 2007, Sam Ravnborg wrote:
>
> > A summary of what is planned to be submitted in next merge window for kbuild.
> > The shortlog below have additional details but the headlines are:
> ...
> > o add script to find unused kconfig symbols (try it!)
>
> based on my experiences with this, unless you filter carefully, you're
> going to end up with a *whack* of false positives given the number of
> developers who elect to name their local macros starting with a prefix
> of "CONFIG_". good luck dealing with *that*. :-)
This is useful for specific people but not for kernel janitorial fodder.
As you already experience the amount of false positive are too high.

But for a developer of a module it is no deal to ignore the false
positives.

It is for godd reasons not integrated in the build process.

Sam

2007-09-16 15:24:16

by Robert P. J. Day

[permalink] [raw]
Subject: Re: kbuild update

On Sun, 16 Sep 2007, Sam Ravnborg wrote:

> On Sun, Sep 16, 2007 at 08:58:03AM -0400, Robert P. J. Day wrote:
> > On Sun, 16 Sep 2007, Sam Ravnborg wrote:
> >
> > > A summary of what is planned to be submitted in next merge window for kbuild.
> > > The shortlog below have additional details but the headlines are:
> > ...
> > > o add script to find unused kconfig symbols (try it!)
> >
> > based on my experiences with this, unless you filter carefully, you're
> > going to end up with a *whack* of false positives given the number of
> > developers who elect to name their local macros starting with a prefix
> > of "CONFIG_". good luck dealing with *that*. :-)

> This is useful for specific people but not for kernel janitorial
> fodder. As you already experience the amount of false positive are
> too high.
>
> But for a developer of a module it is no deal to ignore the false
> positives.
>
> It is for godd reasons not integrated in the build process.

right, i agree completely. if it were absolutely reliable in
generating *only* actual unused symbols, then that *might* (i stress,
*might*) be a viable argument for making it part of the Kbuild system.

but, really, if you can whip off a script that does most of the job in
a few minutes, there's really no motivation to then spend hours trying
to nail those last few harmless bits of irrelevant output.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

2007-09-16 19:25:43

by Andrew Morton

[permalink] [raw]
Subject: Re: kbuild update

On Sun, 16 Sep 2007 08:58:03 -0400 (EDT) "Robert P. J. Day" <[email protected]> wrote:

> On Sun, 16 Sep 2007, Sam Ravnborg wrote:
>
> > A summary of what is planned to be submitted in next merge window for kbuild.
> > The shortlog below have additional details but the headlines are:
> ...
> > o add script to find unused kconfig symbols (try it!)
>
> based on my experiences with this, unless you filter carefully, you're
> going to end up with a *whack* of false positives given the number of
> developers who elect to name their local macros starting with a prefix
> of "CONFIG_". good luck dealing with *that*. :-)

box:/usr/src/linux-2.6.23-rc6> grep -r '^[ ]*#[ ]*define[ ]*CONFIG_' . | wc -l
415

bah. They're all bugs - The CONFIG_foo namespace is (should be) reserved in
kernel coding.


2007-09-16 20:37:31

by Sam Ravnborg

[permalink] [raw]
Subject: Re: kbuild update

On Sun, Sep 16, 2007 at 12:23:43PM -0700, Andrew Morton wrote:
> On Sun, 16 Sep 2007 08:58:03 -0400 (EDT) "Robert P. J. Day" <[email protected]> wrote:
>
> > On Sun, 16 Sep 2007, Sam Ravnborg wrote:
> >
> > > A summary of what is planned to be submitted in next merge window for kbuild.
> > > The shortlog below have additional details but the headlines are:
> > ...
> > > o add script to find unused kconfig symbols (try it!)
> >
> > based on my experiences with this, unless you filter carefully, you're
> > going to end up with a *whack* of false positives given the number of
> > developers who elect to name their local macros starting with a prefix
> > of "CONFIG_". good luck dealing with *that*. :-)
>
> box:/usr/src/linux-2.6.23-rc6> grep -r '^[ ]*#[ ]*define[ ]*CONFIG_' . | wc -l
> 415
>
> bah. They're all bugs - The CONFIG_foo namespace is (should be) reserved in
> kernel coding.

I get (after a bit more filtering 349 hits of which 182 are outside drivers/

Of the 182 the 25 of them are in arch specific code.

I se no good reasons to address this unless we touch code in that area anyway.
But avoiding new entries are good.

Sam