Rusty Russell | 1 Jul 2009 07:00
Picon
Gravatar

Re: [PATCH] reduce export symbol CRC table size on 64-bit archs

On Tue, 30 Jun 2009 09:21:52 pm Jan Beulich wrote:
> Since these CRCs are really only 32-bit quantities, there's no need to
> store them in 64-bit slots. Since, however, gcc doesn't allow
> respective initializations, asm() constructs get used to create the CRC
> tables (and its for that reason that the patch only makes x86-64 and
> ia64 utilize that functionality, as I can't verify this doesn't break
> in some subtle way elsewhere).

Hmm, can we change the build system to just link this in as a normal table, 
rather than use linker tricks?

Then genksyms would just spit out a C file we could compile and link into final 
vmlinux.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jan Beulich | 1 Jul 2009 09:00
Picon
Favicon

Re: [PATCH] reduce export symbol CRC table size on 64-bit archs

>>> Rusty Russell <rusty <at> rustcorp.com.au> 01.07.09 07:00 >>>
>On Tue, 30 Jun 2009 09:21:52 pm Jan Beulich wrote:
>> Since these CRCs are really only 32-bit quantities, there's no need to
>> store them in 64-bit slots. Since, however, gcc doesn't allow
>> respective initializations, asm() constructs get used to create the CRC
>> tables (and its for that reason that the patch only makes x86-64 and
>> ia64 utilize that functionality, as I can't verify this doesn't break
>> in some subtle way elsewhere).
>
>Hmm, can we change the build system to just link this in as a normal table, 
>rather than use linker tricks?
>
>Then genksyms would just spit out a C file we could compile and link into final 
>vmlinux.

That's going to be non-trivial, because of the ordering that's required to be
identical between the symbol and the CRC tables. Basically that would mean
that genksyms would need to look at either the assembly output or the
object file, which would further slow down the build process. Compared to
that the asm() solution in the patch sent seems more strait forward (despite
it possibly looking convoluted at the first glance).

Jan

Robert P. J. Day | 1 Jul 2009 19:36
Picon
Gravatar

finding inappropriate "tristate" variables that should be bool?


  a while back, i wrote a script (whose logic i don't even recognize
anymore) that scanned the kernel tree, looking for CONFIG variables
that were defined as "tristate" but whose usage in a Makefile seemed
to suggest that they should simply be boolean.

  for instance, one of the variables flagged:

scripts/Makefile IKCONFIG
./init/Kconfig:config IKCONFIG
./init/Kconfig-	tristate "Kernel .config support"

sure enough, if you run "make menuconfig", under "General setup," the
selection "Kernel .config support" can be selected as modular, even
though that doesn't seem to make much sense since its usage in
scripts/Makefile is:

  hostprogs-$(CONFIG_IKCONFIG)     += bin2c

for which a modular selection seems weird.  does that make any sense?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
(Continue reading)

Michal Marek | 3 Jul 2009 16:45
Picon
Gravatar

Re: [PATCH] kbuild: generate modules.builtin

On Tue, May 26, 2009 at 05:25:40PM +0200, Michal Marek wrote:
> Known issues (found when comparing results with allyesconfig and
> allmodconfig):
>  * ALSA makefiles do some substitutions on the CONFIG_*
>    variables sometimes, which breaks the logic if the alsa modules are
>    built-in. Patch sent to alsa-devel.
>  * samples/kobject/*.o could be compiled built-in, but doesn't show up
>    in modules.builtin (and not even in vmlinux.o). Patch sent to Greg to
>    make it module-only.

These two are merged already.

>  * net/{8021q/vlan_core,ethernet/pe2,ipv6/inet6_hashtables}.o are always
>    built-in, even though the corresponding config option is tristate:
>    obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
>    The result is that modules.builtin can contain three built-in
>    "modules" that can't possibly exist as modules. No fix for this so far,
>    as it is not a big issue IMO.

I hope this one is not a problem.

I rebased the patch on top of current kbuild-next.git. What do you think
about it? Do you agree on the modules.builtin file name and format? I'd
like to add support for this to module-init-tools.

Subject: [PATCH] kbuild: generate modules.builtin

To make it easier for tools like mkinitrd to detect whether a needed
module is missing or whether it is compiled into the kernel, install a
modules.builtin file listing all modules built into the kernel. This is
(Continue reading)

Sam Ravnborg | 3 Jul 2009 23:43
Gravatar

[GIT] kbuild fixes

Hi Linus.

- various .gitignore updates
- disabling of -Wformat-security
  We looked at it and 'fixing' the warnings was not pleasant
- fixes/improvements for the newly introduced macros in asm-generic/vmlinux.lds.h

Nothing earth-shaking..
And it has been in -next for a few days with no issues.

I am heading for a two week vacation in Sweden and will
be offline in that period.
Enjoy the kernel hacking while I enjoy my vacation :-) 

	Sam

The following changes since commit 4075ea8c54a7506844a69f674990241e7766357b:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://git.kernel.org/.../bp/bp

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes.git master

Amerigo Wang (2):
      gitignore: ignore gcov output files
      kbuild: finally remove the obsolete variable $TOPDIR

Floris Kraak (1):
      Kbuild: Disable the -Wformat-security gcc flag
(Continue reading)

Floris Kraak | 3 Jul 2009 23:53
Picon
Gravatar

Re: [GIT] kbuild fixes

On Fri, Jul 3, 2009 at 11:43 PM, Sam Ravnborg<sam <at> ravnborg.org> wrote:
>
> - disabling of -Wformat-security
>  We looked at it and 'fixing' the warnings was not pleasant

The alternative is roughly 136 'trivial' patches to shut them all up*
and one to turn this flag on unconditionally to prevent hackers from
adding more of them after that ;-)

The alternative to *that* is improving on this silly flag:
- Either finding some way to teach GCC how to not emit warnings about
usage that is entirely sane.
- Or finding some way to teach some other build tool to catch unsafe
usage without polluting the build with false positives.

Take your pick.

*) While I can't give you 100% certainty about every warning I know
for a fact the vast majority of the warnings at least consists of
false positives so there'd be no other benefit from them except a
quieter kernel build on certain distro's ;-)

Regards,
Floris
---
'Or lawyers may say, “But if I decline, someone else will do it. So
what is gained?” My reply: “Let someone else do it. But not you. Honor
is personal. Worry about yourself.  You don’t get a pass from moral
responsibility because you acted for a client.”

(Continue reading)

Robert P. J. Day | 5 Jul 2009 15:46
Picon
Gravatar

[PATCH] KBUILD: Correct initramfs compression comment.


Fix the Makefile comment since bzip2 is now supported.

Signed-off-by: Robert P. J. Day <rpjday <at> crashcourse.ca>

---

diff --git a/usr/Makefile b/usr/Makefile
index 245145a..1e6a9e4 100644
--- a/usr/Makefile
+++ b/usr/Makefile
 <at>  <at>  -6,7 +6,7  <at>  <at>  klibcdirs:;
 PHONY += klibcdirs

-# Gzip, but no bzip2
+# Gzip
 suffix_$(CONFIG_INITRAMFS_COMPRESSION_GZIP)   = .gz

 # Bzip2

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Linked In:                             http://www.linkedin.com/in/rpjday
Twitter:                                       http://twitter.com/rpjday
========================================================================
--
(Continue reading)

maximilian attems | 5 Jul 2009 20:17
Picon

[PATCH] kbuild: deb-pkg fix install scripts for posix sh

bash versus dash and posh disagree on expanding $ <at>  within double quotes:
export x="$ <at> "
see http://bugs.debian.org/381091 for details
just use the arglist with $*.

dpkg: error processing linux-image-2.6.31-rc1_2.6.31-rc1-18_i386.deb (--install):
 subprocess pre-installation script returned error exit status 2
export: 6: 2.6.31-rc1-18: bad variable name
fixes http://bugzilla.kernel.org/show_bug.cgi?id=13567

seen on Ubuntu as there dash is the default sh,
versus bash on Debian.

Reported-by: Pauli <suokkos <at> gmail.com>
Cc: Frans Pop <elendil <at> planet.nl>
Cc: Andres Salomon <dilinger <at> debian.org>
Signed-off-by: maximilian attems <max <at> stro.at>
---
 scripts/package/builddeb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b19f1f4..8b357b0 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
 <at>  <at>  -89,7 +89,7  <at>  <at>  for script in postinst postrm preinst prerm ; do
 set -e

 # Pass maintainer script parameters to hook scripts
-export DEB_MAINT_PARAMS="\$ <at> "
(Continue reading)

John Williams | 6 Jul 2009 03:24
Favicon

Re: Update/override CONFIG_ during kbuild?

On Tue, Jun 30, 2009 at 2:41 AM, Randy Dunlap <randy.dunlap <at> oracle.com> wrote:
>
> On Mon, 29 Jun 2009 15:26:51 +1000 John Williams wrote:
>
> > Is there a mechanism to override or update a CONFIG_ value during the
> > make process?
> >
> > In the MicroBlaze architecture we have a highly configurable CPU -
> > various ALU options can be enabled or disabled at will during the
> > hardware build phase.  We have several Kconfig options that must match
> > this, and which are used to generate the appropriate CFLAGS during
> > kernel build.  e.g.
> >
> > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
> > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
> > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
> >
> [snip]

>
> > Thus, returning to the question - is there a sane way that we can
> > override or force the relevant CONFIG_ values, from within the
> > Makefile itself?   Or, must we resort to a script, and do it as a
> > preprocessing step?  Is there a reasonable way to still integrate this
> > into the kernel build phase?
>
> I thought that it was possible to override CONFIG_ symbols on the
> "make" command line, and my limited testing confirms that.
>
> E.g.:
(Continue reading)

Arnaud Lacombe | 6 Jul 2009 06:07
Picon
Gravatar

[PATCH 1/2] Kconfig: variable argument lists needs `stdarg.h'

Fix build on non GNU based platforms.
---
 scripts/kconfig/lxdialog/util.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/lxdialog/util.c b/scripts/kconfig/lxdialog/util.c
index 86d95cc..f2375ad 100644
--- a/scripts/kconfig/lxdialog/util.c
+++ b/scripts/kconfig/lxdialog/util.c
 <at>  <at>  -19,6 +19,8  <at>  <at> 
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */

+#include <stdarg.h>
+
 #include "dialog.h"

 struct dialog_info dlg;
--

-- 
1.6.3.3.385.g60647.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane