[PATCH 0/5] kbuild

[PATCH 0/5] kbuild

[Sam Ravnborg]

Hi Andrew. Here follows a number of kbuild patches.

The first replaces kbuild-specify-default-target-during-configuration.patch

They have seen ligiht testing here, but on the other hand the do not touch
any critical part of kbuild.

Patches:

default kernel image:		Specify default target at config
				time rather then hardcode it.
				Only enabled for i386 for now.
move rpm to scripts/package: 	Move rpm support so we are ready for
				more package types
add deb-pkg target:		Pack kernel in debian format
make clean improved:		make clean removes a few more files
external module build doc:	Add documentation for building external modules


Above changes can be pulled from linux-sam.bkbits.net/kbuild:
bk pull bk://linux-sam.bkbits.net/kbuild
(Being updated as I type)

Patches follows as individual mails.

If anyone like to cook up a targz-pkg target please feel free.

	Sam

Re: [PATCH 1/5] kbuild: default kernel image

[Sam Ravnborg]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/07 22:56:31+02:00 sam@mars.ravnborg.org 
#   kbuild: Default kernel image defined in .config
#   
#   During kernel configuration the default kernel image is now being selected.
#   When compiling the kernel the user no longer needs to look up the
#   selected kernel imgae in either the $(ARCH) makefile or in 'make help'.
#   The more natural choice is to select the kernel image during kernel
#   the configuration.
#   The menu is located at the very top, since the other logical place
#   "general setup" did not have an opening for architecture specific
#   options.
#   The added benefit is that packaging tools now have access to the selected
#   kernel imgae, and do not have to do wild guessing based on architectures.
#   
#   This patch only converts i386, but other architectures should be easy to convert.
#   The patch is backward compatible, other architecture will not break due to this change.
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# arch/i386/Makefile
#   2004/06/07 22:56:16+02:00 sam@mars.ravnborg.org +10 -8
#   Teach i386 makefile to use full path to kernel image, along the well known short versions of the names
# 
# arch/i386/Kconfig
#   2004/06/07 22:56:16+02:00 sam@mars.ravnborg.org +36 -0
#   Add i386 config options to select kernel image
# 
# Makefile
#   2004/06/07 22:56:16+02:00 sam@mars.ravnborg.org +10 -7
#   Use the new default target selected during kernel configuration.
#   When no kernel image is selected during configuaration vmlinux is assumed default.
# 
diff -Nru a/Makefile b/Makefile
--- a/Makefile	2004-06-14 22:26:01 +02:00
+++ b/Makefile	2004-06-14 22:26:01 +02:00
@@ -409,13 +409,6 @@
 
 scripts_basic: include/linux/autoconf.h
 
-
-# That's our default target when none is given on the command line
-# Note that 'modules' will be added as a prerequisite as well, 
-# in the CONFIG_MODULES part below
-
-all:	vmlinux
-
 # Objects we will link into vmlinux / subdirs we need to visit
 init-y		:= init/
 drivers-y	:= drivers/ sound/
@@ -448,6 +441,16 @@
 endif
 
 include $(srctree)/arch/$(ARCH)/Makefile
+
+# Selected kernel image to build in .config, assuming vmlinux
+# if CONFIG_KERNEL_IMAGE is empty (not defined)
+KERNEL_IMAGE := $(if $(CONFIG_KERNEL_IMAGE), \
+                     $(subst ",,$(CONFIG_KERNEL_IMAGE)), vmlinux)
+
+# The all: target has the kernel selected in .config as prerequisite.
+# Hereby user only have to issue 'make' to build the kernel, including
+# selected kernel
+all: $(KERNEL_IMAGE)
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 CFLAGS		+= -Os
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig	2004-06-14 22:26:01 +02:00
+++ b/arch/i386/Kconfig	2004-06-14 22:26:01 +02:00
@@ -29,6 +29,42 @@
 	bool
 	default y
 
+choice
+	prompt "Default kernel image"
+	default KERNEL_IMAGE_BZIMAGE
+	help
+	  Specify which kernel image to be build when executing 'make' with
+	  no arguments.
+
+config KERNEL_IMAGE_BZIMAGE
+	bool "bzImage - Compressed kernel image"
+	help
+	  bzImage - located at arch/i386/boot/bzImage.
+	  bzImage can accept larger kernels than zImage
+	
+config KERNEL_IMAGE_ZIMAGE
+	bool "zImage - Compressed kernel image"
+	help
+	  zImage - located at arch/i386/boot/zImage.
+	  zImage is seldom used. zImage supports smaller kernels than bzImage,
+	  and is only used in special situations.
+
+config KERNEL_IMAGE_VMLINUX
+	bool "vmlinux - the bare kernel"
+	help
+	  vmlinux - located at the root of the kernel tree
+	  vmlinux contains the kernel image with no additional bootloader.
+	  vmlinux is seldom used as target for i386.
+
+endchoice
+
+config KERNEL_IMAGE
+	string 
+	default arch/i386/boot/bzImage if KERNEL_IMAGE_BZIMAGE
+	default arch/i386/boot/zImage  if KERNEL_IMAGE_ZIMAGE
+	default vmlinux                if KERNEL_IMAGE_VMLINUX
+
+
 source "init/Kconfig"
 
 
diff -Nru a/arch/i386/Makefile b/arch/i386/Makefile
--- a/arch/i386/Makefile	2004-06-14 22:26:01 +02:00
+++ b/arch/i386/Makefile	2004-06-14 22:26:01 +02:00
@@ -116,18 +116,20 @@
 
 boot := arch/i386/boot
 
-.PHONY: zImage bzImage compressed zlilo bzlilo \
-	zdisk bzdisk fdimage fdimage144 fdimage288 install
+# Shortcut targets to different i386 targets.
+.PHONY: bzImage zImage compressed
+bzImage:    $(boot)/bzImage
+zImage:     $(boot)/zImage
+compressed: $(boot)/zImage	# Deprecated, will be deleted later
 
-all: bzImage
+# Target's that install the kernel
+.PHONY: zlilo bzlilo zdisk bzdisk fdimage fdimage144 fdimage288 install
 
 BOOTIMAGE=arch/i386/boot/bzImage
-zImage zlilo zdisk: BOOTIMAGE=arch/i386/boot/zImage
+zlilo zdisk: BOOTIMAGE=arch/i386/boot/zImage
 
-zImage bzImage: vmlinux
-	$(Q)$(MAKE) $(build)=$(boot) $(BOOTIMAGE)
-
-compressed: zImage
+$(boot)/zImage $(boot)/bzImage: vmlinux
+	$(Q)$(MAKE) $(build)=$(boot) $@
 
 zlilo bzlilo: vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(BOOTIMAGE) zlilo

Re: [PATCH 1/5] kbuild: default kernel image

[Russell King]

On Mon, Jun 14, 2004 at 10:44:05PM +0200, Sam Ravnborg wrote:
> #   When compiling the kernel the user no longer needs to look up the
> #   selected kernel imgae in either the $(ARCH) makefile or in 'make help'.
> #   The more natural choice is to select the kernel image during kernel
> #   the configuration.

I'm slightly scared of this.  Historically, there's already pressure
from boot loader people on ARM to include random file formats to suit
their own boot loaders.

In the first place, ARM had Image and zImage and that was it.  It was
well defined.  Then people decided that gzipped Image would be nice
and they'd merge the zlib code into their boot loader.  I think there's
even some people who use gzipped zImage...!

Then ARMboot came along and we eventually ended up with uboot-style
wrappings to support uboot / ARMboot, which require an external program
to be installed on the host system called "mkimage" (which, incidentally
is an incredibly bad choice of name.)

People also came up with the idea of using the ELF file directly and
having the boot loader parse the ELF file.  I wouldn't put it past
someone to want gzipped ELF as well.

There's also srec to support serially downloaded images as well.

So, in total, we have boot loaders which want:

  - Image
  - zImage
  - gzipped Image
  - gzipped zImage
  - uboot
  - ELF
  - srec

Basically this is somewhere I don't want to go.  My position is that
if boot loaders want to have their own proprietary formats, they
should do whatever manipulation to the kernel image is necessary as
a post processing step themselves from one of the two standard kernel
formats - Image or zImage.

However, the problem of offering users all these options is that their
first question will be "huh, which one of these 7 do I want?" rather
than everyone knowing that they need the kernel build to produce either
an Image or zImage and the boot loader documentation telling them what
to do with it next.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 1/5] kbuild: default kernel image

[Sam Ravnborg]

On Mon, Jun 14, 2004 at 10:05:49PM +0100, Russell King wrote:
> 
> I'm slightly scared of this.  Historically, there's already pressure
> from boot loader people on ARM to include random file formats to suit
> their own boot loaders.
> 
> In the first place, ARM had Image and zImage and that was it.  It was
> well defined.  Then people decided that gzipped Image would be nice
> and they'd merge the zlib code into their boot loader.  I think there's
> even some people who use gzipped zImage...!
> 
> Then ARMboot came along and we eventually ended up with uboot-style
> wrappings to support uboot / ARMboot, which require an external program
> to be installed on the host system called "mkimage" (which, incidentally
> is an incredibly bad choice of name.)
> 
> People also came up with the idea of using the ELF file directly and
> having the boot loader parse the ELF file.  I wouldn't put it past
> someone to want gzipped ELF as well.
> 
> There's also srec to support serially downloaded images as well.
> 
> So, in total, we have boot loaders which want:
> 
>   - Image
>   - zImage
>   - gzipped Image
>   - gzipped zImage
>   - uboot
>   - ELF
>   - srec
> 
> Basically this is somewhere I don't want to go.  My position is that
> if boot loaders want to have their own proprietary formats, they
> should do whatever manipulation to the kernel image is necessary as
> a post processing step themselves from one of the two standard kernel
> formats - Image or zImage.
> 
> However, the problem of offering users all these options is that their
> first question will be "huh, which one of these 7 do I want?" rather
> than everyone knowing that they need the kernel build to produce either
> an Image or zImage and the boot loader documentation telling them what
> to do with it next.

The advantage is that you now have a good place to document all of
these formats - your Kconfig file.
And you select the default target for the user.

How did I know uboot required mkimage before - now it can be documented
in Kconfig.
So the situation above is actually a good example why it is whortwhile
to move the kernel image selection to the config stage.

If they all should be part of the kernel build is another discussion.

	Sam

Re: [PATCH 1/5] kbuild: default kernel image

[Russell King]

On Tue, Jun 15, 2004 at 06:40:20AM +0200, Sam Ravnborg wrote:
> The advantage is that you now have a good place to document all of
> these formats - your Kconfig file.
> And you select the default target for the user.
> 
> How did I know uboot required mkimage before - now it can be documented
> in Kconfig.
> So the situation above is actually a good example why it is whortwhile
> to move the kernel image selection to the config stage.
> 
> If they all should be part of the kernel build is another discussion.

You missed my point.

How does a user know which format they need to build the kernel with
_if_ the kernel configuration contains all the formats and the boot
loader documentation fails to mention it?

Sure you can document each format in minute detail, but that doesn't
tell the user anything useful.

As I tried to point out, boot loaders on ARM historically seem to have
been "My First ARM Project" type things so there's lots of them out
there - there aren't 3 or so found on x86.

AFAIAC, if the boot loader does not support the standard Image or
zImage format, both of which are the fully documented "official"
ARM kernel formats, it is up to the boot loader to provide whatever
scripts or programs are needed to manipulate the output of the kernel
build to whatever the boot loader wants.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 1/5] kbuild: default kernel image

[Christoph Hellwig]

On Tue, Jun 15, 2004 at 09:38:07AM +0100, Russell King wrote:
> AFAIAC, if the boot loader does not support the standard Image or
> zImage format, both of which are the fully documented "official"
> ARM kernel formats, it is up to the boot loader to provide whatever
> scripts or programs are needed to manipulate the output of the kernel
> build to whatever the boot loader wants.

And we have /sbin/installkernel and ~/bin/installkernel as defined hooks
for that.  No need to support everything and a kitchensink in the kernel
build process.  In fact I'd love to reduce what the kernel builds to just
vmlinux and vmlinux.gz, but I guess all those lilo user will kill me ;-)

Re: [PATCH 1/5] kbuild: default kernel image

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 09:59:52AM +0100, Christoph Hellwig wrote:
> On Tue, Jun 15, 2004 at 09:38:07AM +0100, Russell King wrote:
> > AFAIAC, if the boot loader does not support the standard Image or
> > zImage format, both of which are the fully documented "official"
> > ARM kernel formats, it is up to the boot loader to provide whatever
> > scripts or programs are needed to manipulate the output of the kernel
> > build to whatever the boot loader wants.
> 
> And we have /sbin/installkernel and ~/bin/installkernel as defined hooks
> for that.

installkernel is a hack to install a kernel for current machine mainly.
Not what I consider a good generic solution.

> In fact I'd love to reduce what the kernel builds to just
> vmlinux and vmlinux.gz, but I guess all those lilo user will kill me ;-)
I do not see the point in this.
Better make life easier - but in a nice and structured way.
Take a look at arch/ppc/boot/simple to see that the bootloader step is not trivial..
The concept with a clean and lean kernel that cannot be used in real-life without
doing lot's of stuff is a dead end.


	Sam

Re: [PATCH 1/5] kbuild: default kernel image

[Russell King]

On Tue, Jun 15, 2004 at 11:07:39PM +0200, Sam Ravnborg wrote:
> Better make life easier - but in a nice and structured way.

Life /was/ easy when there was just zImage and Image on ARM.  All you
had to do was decide whether you wanted a compressed or uncompressed
binary image of the kernel, where compressed images were the normal.

And this is the way I'd preferred it to stay since we have a nice
sane structured idea of what we provide without any major "what
file format do I need" problems.

The problem starts happening when boot loaders think they can dictate
to the kernel what format they want the kernel to be in - at that
point the number of kernel image formats and methods to boot the
kernel increases and everything gets a lot more complex.

This is the whole basis of my argument.  We shouldn't make it easy
for people to extend this stupid idea that the boot loader defines
the format which the kernel shall be in.  It's the _wrong_ idea.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 1/5] kbuild: default kernel image

[Tom Rini]

On Tue, Jun 15, 2004 at 11:07:39PM +0200, Sam Ravnborg wrote:
> On Tue, Jun 15, 2004 at 09:59:52AM +0100, Christoph Hellwig wrote:
> > In fact I'd love to reduce what the kernel builds to just
> > vmlinux and vmlinux.gz, but I guess all those lilo user will kill me ;-)
> I do not see the point in this.
> Better make life easier - but in a nice and structured way.
> Take a look at arch/ppc/boot/simple to see that the bootloader step is not trivial..

That's not a good example of why it's not trivial, really :)
- 2/5th are what final frob'ing do I need to run for the f/w.
- 1/5th are what extension to use in /tftpboot/
- 2/5th are what platform-specific bits do I need
And 1 (so I'm a bit of 100%, shoot me :)) is for an actual CONFIG
option, that we only use in the bootloader code as on very small memory
machines you might not want to load at the default address for your
platform.

We've actually talked about moving all of that code out and using, for
example, a stripped down U-Boot (the point of arch/ppc/boot/ stuffs is
to not depend on the f/w to do anything aside from load us into memory)
that'd just load up the kernel and let it go.  All of the information
that would be needed by such a program are already avail via IKCONFIG
(and could be stripped out afterwards I believe for size).

> The concept with a clean and lean kernel that cannot be used in real-life without
> doing lot's of stuff is a dead end.

Define "lot's of stuff".  IIRC, sparc* has always been just a vmlinux,
and 99% of pmac users use yaboot + vmlinux.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 1/5] kbuild: default kernel image

[Tom Rini]

On Tue, Jun 15, 2004 at 09:38:07AM +0100, Russell King wrote:

> On Tue, Jun 15, 2004 at 06:40:20AM +0200, Sam Ravnborg wrote:
> > The advantage is that you now have a good place to document all of
> > these formats - your Kconfig file.
> > And you select the default target for the user.
> > 
> > How did I know uboot required mkimage before - now it can be documented
> > in Kconfig.
> > So the situation above is actually a good example why it is whortwhile
> > to move the kernel image selection to the config stage.
> > 
> > If they all should be part of the kernel build is another discussion.
> 
> You missed my point.
> 
> How does a user know which format they need to build the kernel with
> _if_ the kernel configuration contains all the formats and the boot
> loader documentation fails to mention it?

I think what Sam was saying is that you document what boards are
supported by what firmwares, in the Kconfig.  But what I don't think Sam
saw would be just how ugly that's going to look (and become another
point where every new board port touches, and possibly conflicts with
another new board port).

> As I tried to point out, boot loaders on ARM historically seem to have
> been "My First ARM Project" type things so there's lots of them out
> there - there aren't 3 or so found on x86.

And that's another good reason not to.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 1/5] kbuild: default kernel image

[Russell King]

On Tue, Jun 15, 2004 at 08:38:36AM -0700, Tom Rini wrote:
> I think what Sam was saying is that you document what boards are
> supported by what firmwares, in the Kconfig.  But what I don't think Sam
> saw would be just how ugly that's going to look (and become another
> point where every new board port touches, and possibly conflicts with
> another new board port).

Indeed - however, take a peek at arch/arm/tools/mach-types - that's a
list of the various machines which the ARM kernel may or may not have
been ported to.  Something suggests that creating a list of machine
types in the Kconfig help documentation will probably be unmanageable.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 2/5] kbuild: move rpm to scripts/package

[Sam Ravnborg]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 21:22:52+02:00 sam@mars.ravnborg.org 
#   kbuild: Move rpm target o scripts/package
#   
#   To prepare for support of more packages types move suport for rpm to
#   a new directory: scripts/package.
#   Use the generic target "%-pkg" so the new target for rpm is now: rpm-pkg.
#   Kept the old rpm target for backward compatibility.
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# scripts/package/Makefile
#   2004/06/14 21:22:37+02:00 sam@mars.ravnborg.org +55 -0
# 
# scripts/package/mkspec
#   2004/06/14 21:22:37+02:00 sam@mars.ravnborg.org +6 -15
#   Use $KERNEL_IMAGE to locate compiled image, hereby no hardcoding to
#   different architectures.
#   Separate make clean && make steps
# 
# scripts/package/Makefile
#   2004/06/14 21:22:37+02:00 sam@mars.ravnborg.org +0 -0
#   BitKeeper file /home/sam/bk/kbuild/scripts/package/Makefile
# 
# scripts/Makefile
#   2004/06/14 21:22:37+02:00 sam@mars.ravnborg.org +1 -1
#   Clean in package/ as well
# 
# Makefile
#   2004/06/14 21:22:37+02:00 sam@mars.ravnborg.org +14 -32
#   Moved rpm target to scripts/package/Makefile
#   Exported KERNEL_IMAGE to give access to it outside this Makefile
#   Add support for the scripts/package/* stuff
# 
# scripts/packages/mkspec
#   2004/06/07 23:03:27+02:00 sam@mars.ravnborg.org +0 -0
#   Rename: scripts/mkspec -> scripts/packages/mkspec
# 
diff -Nru a/Makefile b/Makefile
--- a/Makefile	2004-06-14 22:25:51 +02:00
+++ b/Makefile	2004-06-14 22:25:51 +02:00
@@ -290,8 +290,6 @@
 OBJCOPY		= $(CROSS_COMPILE)objcopy
 OBJDUMP		= $(CROSS_COMPILE)objdump
 AWK		= awk
-RPM 		:= $(shell if [ -x "/usr/bin/rpmbuild" ]; then echo rpmbuild; \
-		    	else echo rpm; fi)
 GENKSYMS	= scripts/genksyms/genksyms
 DEPMOD		= /sbin/depmod
 KALLSYMS	= scripts/kallsyms
@@ -444,8 +442,8 @@
 
 # Selected kernel image to build in .config, assuming vmlinux
 # if CONFIG_KERNEL_IMAGE is empty (not defined)
-KERNEL_IMAGE := $(if $(CONFIG_KERNEL_IMAGE), \
-                     $(subst ",,$(CONFIG_KERNEL_IMAGE)), vmlinux)
+export KERNEL_IMAGE := $(if $(CONFIG_KERNEL_IMAGE), \
+                            $(subst ",,$(CONFIG_KERNEL_IMAGE)), vmlinux)
 
 # The all: target has the kernel selected in .config as prerequisite.
 # Hereby user only have to issue 'make' to build the kernel, including
@@ -798,7 +796,7 @@
 
 # Directories & files removed with 'make clean'
 CLEAN_DIRS  += $(MODVERDIR)
-CLEAN_FILES +=	vmlinux System.map kernel.spec \
+CLEAN_FILES +=	vmlinux System.map \
                 .tmp_kallsyms* .tmp_version .tmp_vmlinux*
 
 # Directories & files removed with 'make mrproper'
@@ -851,37 +849,19 @@
 		-o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
 		-type f -print | xargs rm -f
 
-# RPM target
-# ---------------------------------------------------------------------------
-
-.PHONY: rpm
 
-# Remove hyphens since they have special meaning in RPM filenames
-KERNELPATH=kernel-$(subst -,,$(KERNELRELEASE))
+# Packaging of the kernel to various formats
+# ---------------------------------------------------------------------------
+# rpm target kept for backward compatibility
+package-dir	:= $(srctree)/scripts/package
 
-#	If you do a make spec before packing the tarball you can rpm -ta it
+.PHONY: %-pkg rpm
 
-spec:
-	$(CONFIG_SHELL) $(srctree)/scripts/mkspec > $(objtree)/kernel.spec
-
-#	a) Build a tar ball
-#	b) generate an rpm from it
-#	c) and pack the result
-#	- Use /. to avoid tar packing just the symlink
-
-rpm:	clean spec
-	set -e; \
-	cd .. ; \
-	ln -sf $(srctree) $(KERNELPATH) ; \
-	tar -cvz $(RCS_TAR_IGNORE) -f $(KERNELPATH).tar.gz $(KERNELPATH)/. ; \
-	rm $(KERNELPATH)
-
-	set -e; \
-	$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version;\
-	mv -f $(objtree)/.tmp_version $(objtree)/.version;
+%pkg: FORCE
+	$(Q)$(MAKE) -f $(package-dir)/Makefile $@
+rpm: FORCE
+	$(Q)$(MAKE) -f $(package-dir)/Makefile $@
 
-	$(RPM) --target $(UTS_MACHINE) -ta ../$(KERNELPATH).tar.gz
-	rm ../$(KERNELPATH).tar.gz
 
 # Brief documentation of the typical targets used
 # ---------------------------------------------------------------------------
@@ -908,6 +888,8 @@
 	@echo  '  tags/TAGS	  - Generate tags file for editors'
 	@echo  '  cscope	  - Generate cscope index'
 	@echo  '  checkstack      - Generate a list of stack hogs'
+	@echo  'Kernel packaging:'
+	@$(MAKE) -f $(package-dir)/Makefile help
 	@echo  ''
 	@echo  'Documentation targets:'
 	@$(MAKE) -f $(srctree)/Documentation/DocBook/Makefile dochelp
diff -Nru a/scripts/Makefile b/scripts/Makefile
--- a/scripts/Makefile	2004-06-14 22:25:51 +02:00
+++ b/scripts/Makefile	2004-06-14 22:25:51 +02:00
@@ -13,7 +13,7 @@
 subdir-$(CONFIG_MODVERSIONS)	+= genksyms
 
 # Let clean descend into subdirs
-subdir-	+= basic lxdialog kconfig
+subdir-	+= basic lxdialog kconfig package
 
 # dependencies on generated files need to be listed explicitly
 
diff -Nru a/scripts/mkspec b/scripts/mkspec
--- a/scripts/mkspec	2004-06-14 22:25:51 +02:00
+++ /dev/null	Wed Dec 31 16:00:00 196900
@@ -1,72 +0,0 @@
-#!/bin/sh
-#
-#	Output a simple RPM spec file that uses no fancy features requring
-#	RPM v4. This is intended to work with any RPM distro.
-#
-#	The only gothic bit here is redefining install_post to avoid 
-#	stripping the symbols from files in the kernel which we want
-#
-#	Patched for non-x86 by Opencon (L) 2002 <opencon@rio.skydome.net>
-#
-# That's the voodoo to see if it's a x86.
-ISX86=`echo ${ARCH:=\`arch\`} | grep -ie i.86`
-if [ ! -z $ISX86 ]; then
-	PC=1
-else
-	PC=0
-fi
-# starting to output the spec
-if [ "`grep CONFIG_DRM=y .config | cut -f2 -d\=`" = "y" ]; then
-	PROVIDES=kernel-drm
-fi
-
-PROVIDES="$PROVIDES kernel-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
-
-echo "Name: kernel"
-echo "Summary: The Linux Kernel"
-echo "Version: "$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION | sed -e "s/-//g"
-# we need to determine the NEXT version number so that uname and
-# rpm -q will agree
-echo "Release: `. $srctree/scripts/mkversion`"
-echo "License: GPL"
-echo "Group: System Environment/Kernel"
-echo "Vendor: The Linux Community"
-echo "URL: http://www.kernel.org"
-echo -n "Source: kernel-$VERSION.$PATCHLEVEL.$SUBLEVEL"
-echo "$EXTRAVERSION.tar.gz" | sed -e "s/-//g"
-echo "BuildRoot: /var/tmp/%{name}-%{PACKAGE_VERSION}-root"
-echo "Provides: $PROVIDES"
-echo "%define __spec_install_post /usr/lib/rpm/brp-compress || :"
-echo "%define debug_package %{nil}"
-echo ""
-echo "%description"
-echo "The Linux Kernel, the operating system core itself"
-echo ""
-echo "%prep"
-echo "%setup -q"
-echo ""
-echo "%build"
-echo "make clean all"
-echo ""
-echo "%install"
-echo 'mkdir -p $RPM_BUILD_ROOT/boot $RPM_BUILD_ROOT/lib $RPM_BUILD_ROOT/lib/modules'
-echo 'INSTALL_MOD_PATH=$RPM_BUILD_ROOT make modules_install'
-# This is the first disagreement between i386 and most others
-if [ $PC = 1 ]; then
-	echo 'cp arch/i386/boot/bzImage $RPM_BUILD_ROOT'"/boot/vmlinuz-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
-else
-	echo 'cp vmlinux $RPM_BUILD_ROOT'"/boot/vmlinux-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
-fi
-# Back on track
-echo 'cp System.map $RPM_BUILD_ROOT'"/boot/System.map-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
-echo 'cp .config $RPM_BUILD_ROOT'"/boot/config-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
-echo ""
-echo "%clean"
-echo '#echo -rf $RPM_BUILD_ROOT'
-echo ""
-echo "%files"
-echo '%defattr (-, root, root)'
-echo "%dir /lib/modules"
-echo "/lib/modules/$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
-echo "/boot/*"
-echo ""
diff -Nru a/scripts/package/Makefile b/scripts/package/Makefile
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/package/Makefile	2004-06-14 22:25:51 +02:00
@@ -0,0 +1,55 @@
+# Makefile for the different targets used to generate full packages of a kernel
+# It uses the generic clean infrastructure of kbuild
+
+# Ignore the following files/directories during tar operation
+TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CVS
+
+
+# RPM target
+# ---------------------------------------------------------------------------
+# The rpm target generates two rpm files:
+# /usr/src/packages/SRPMS/kernel-2.6.7rc2-1.src.rpm
+# /usr/src/packages/RPMS/i386/kernel-2.6.7rc2-1.<arch>.rpm
+# The src.rpm files includes all source for the kernel being built
+# The <arch>.rpm includes kernel configuration, modules etc.
+#
+# Process to create the rpm files
+# a) clean the kernel
+# b) Generate .spec file
+# c) Build a tar ball, using some symlink magic to make sure the kernel version
+#    is first entry in the path
+# d) and pack the result
+# e) generate the rpm files
+# - Use /. to avoid tar packing just the symlink
+
+# Do we have rpmbuild, otherwise fall back to the older rpm
+RPM := $(shell if [ -x "/usr/bin/rpmbuild" ]; then echo rpmbuild; \
+	           else echo rpm; fi)
+
+# Remove hyphens since they have special meaning in RPM filenames
+KERNELPATH := kernel-$(subst -,,$(KERNELRELEASE))
+
+.PHONY: rpm-pkg rpm
+rpm-pkg rpm:
+	$(MAKE) clean
+	$(CONFIG_SHELL) $(srctree)/scripts/package/mkspec > $(objtree)/kernel.spec
+	set -e; \
+	cd .. ; \
+	ln -sf $(srctree) $(KERNELPATH) ; \
+	tar -cz $(RCS_TAR_IGNORE) -f $(KERNELPATH).tar.gz $(KERNELPATH)/. ; \
+	rm $(KERNELPATH)
+
+	set -e; \
+	$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version;\
+	mv -f $(objtree)/.tmp_version $(objtree)/.version;
+
+	$(RPM) --target $(UTS_MACHINE) -ta ../$(KERNELPATH).tar.gz
+	rm ../$(KERNELPATH).tar.gz
+
+clean-rule +=  rm $(objtree)/kernel.spec
+
+# Help text displayed when executing 'make help'
+# ---------------------------------------------------------------------------
+help:
+	@echo  '  rpm-pkg         - Build the kernel as an RPM package'
+
diff -Nru a/scripts/package/mkspec b/scripts/package/mkspec
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/package/mkspec	2004-06-14 22:25:51 +02:00
@@ -0,0 +1,63 @@
+#!/bin/sh
+#
+#	Output a simple RPM spec file that uses no fancy features requring
+#	RPM v4. This is intended to work with any RPM distro.
+#
+#	The only gothic bit here is redefining install_post to avoid 
+#	stripping the symbols from files in the kernel which we want
+#
+#	Patched for non-x86 by Opencon (L) 2002 <opencon@rio.skydome.net>
+#
+
+# starting to output the spec
+if [ "`grep CONFIG_DRM=y .config | cut -f2 -d\=`" = "y" ]; then
+	PROVIDES=kernel-drm
+fi
+
+PROVIDES="$PROVIDES kernel-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+
+echo "Name: kernel"
+echo "Summary: The Linux Kernel"
+echo "Version: "$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION | sed -e "s/-//g"
+# we need to determine the NEXT version number so that uname and
+# rpm -q will agree
+echo "Release: `. $srctree/scripts/mkversion`"
+echo "License: GPL"
+echo "Group: System Environment/Kernel"
+echo "Vendor: The Linux Community"
+echo "URL: http://www.kernel.org"
+echo -n "Source: kernel-$VERSION.$PATCHLEVEL.$SUBLEVEL"
+echo "$EXTRAVERSION.tar.gz" | sed -e "s/-//g"
+echo "BuildRoot: /var/tmp/%{name}-%{PACKAGE_VERSION}-root"
+echo "Provides: $PROVIDES"
+echo "%define __spec_install_post /usr/lib/rpm/brp-compress || :"
+echo "%define debug_package %{nil}"
+echo ""
+echo "%description"
+echo "The Linux Kernel, the operating system core itself"
+echo ""
+echo "%prep"
+echo "%setup -q"
+echo ""
+echo "%build"
+echo "make clean && make"
+echo ""
+echo "%install"
+echo 'mkdir -p $RPM_BUILD_ROOT/boot $RPM_BUILD_ROOT/lib $RPM_BUILD_ROOT/lib/modules'
+
+echo 'INSTALL_MOD_PATH=$RPM_BUILD_ROOT make modules_install'
+echo 'cp $KERNEL_IMAGE $RPM_BUILD_ROOT'"/boot/vmlinuz-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+
+echo 'cp System.map $RPM_BUILD_ROOT'"/boot/System.map-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+
+echo 'cp .config $RPM_BUILD_ROOT'"/boot/config-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+echo ""
+echo "%clean"
+echo '#echo -rf $RPM_BUILD_ROOT'
+echo ""
+echo "%files"
+echo '%defattr (-, root, root)'
+echo "%dir /lib/modules"
+echo "/lib/modules/$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+echo "/boot/*"
+echo ""

Re: [PATCH 3/5] kbuild: add deb-pkg target

[Sam Ravnborg]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 21:44:27+02:00 sam@mars.ravnborg.org 
#   kbuild: Added deb target
#   
#   Script originally from Wichert Akkerman <wichert@wiggy.net>
#   Modified to support multiple architectures.
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# scripts/package/builddeb
#   2004/06/14 21:44:12+02:00 sam@mars.ravnborg.org +79 -0
# 
# scripts/package/builddeb
#   2004/06/14 21:44:12+02:00 sam@mars.ravnborg.org +0 -0
#   BitKeeper file /home/sam/bk/kbuild/scripts/package/builddeb
# 
# scripts/package/Makefile
#   2004/06/14 21:44:12+02:00 sam@mars.ravnborg.org +13 -1
#   Added deb-pkg target
# 
diff -Nru a/scripts/package/Makefile b/scripts/package/Makefile
--- a/scripts/package/Makefile	2004-06-14 22:25:41 +02:00
+++ b/scripts/package/Makefile	2004-06-14 22:25:41 +02:00
@@ -46,10 +46,22 @@
 	$(RPM) --target $(UTS_MACHINE) -ta ../$(KERNELPATH).tar.gz
 	rm ../$(KERNELPATH).tar.gz
 
-clean-rule +=  rm $(objtree)/kernel.spec
+clean-rule +=  rm -f $(objtree)/kernel.spec
+
+# Deb target
+# ---------------------------------------------------------------------------
+# 
+.PHONY: rpm-pkg rpm
+deb-pkg:
+	@$(MAKE)
+	@$(CONFIG_SHELL) $(srctree)/scripts/package/builddeb
+
+clean-rule += && rm -rf debian/
+
 
 # Help text displayed when executing 'make help'
 # ---------------------------------------------------------------------------
 help:
 	@echo  '  rpm-pkg         - Build the kernel as an RPM package'
+	@echo  '  deb-pkg         - Build the kernel as an deb package'
 
diff -Nru a/scripts/package/builddeb b/scripts/package/builddeb
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/package/builddeb	2004-06-14 22:25:41 +02:00
@@ -0,0 +1,79 @@
+#!/bin/sh
+#
+# builddeb 1.2
+# Copyright 2003 Wichert Akkerman <wichert@wiggy.net>
+#
+# Simple script to generate a deb package for a Linux kernel. All the
+# complexity of what to do with a kernel after it is installer or removed
+# is left to other scripts and packages: they can install scripts in the
+# /etc/kernel/{pre,post}{inst,rm}.d/ directories that will be called on 
+# package install and removal.
+
+set -e
+
+# Some variables and settings used throughout the script
+version="$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+tmpdir="$(pwd)/debian/tmp"
+
+# Setup the directory structure
+rm -rf "$tmpdir"
+mkdir -p "$tmpdir/DEBIAN" "$tmpdir/lib" "$tmpdir/boot"
+
+# Build and install the kernel
+cp System.map "$tmpdir/boot/System.map-$version"
+cp .config "$tmpdir/boot/config-$version"
+cp $KERNEL_IMAGE "$tmpdir/boot/vmlinuz-$version"
+
+if grep -q '^CONFIG_MODULES=y' .config ; then
+	INSTALL_MOD_PATH="$tmpdir" make modules_install
+fi
+
+# Install the maintainer scripts
+for script in postinst postrm preinst prerm ; do
+	mkdir -p "$tmpdir/etc/kernel/$script.d"
+	cat <<EOF > "$tmpdir/DEBIAN/$script"
+#!/bin/sh
+
+set -e
+
+test -d /etc/kernel/$script.d && run-parts --arg="$version" /etc/kernel/$script.d
+exit 0
+EOF
+	chmod 755 "$tmpdir/DEBIAN/$script"
+done
+
+name="Kernel Compiler <$(id -nu)@$(hostname -f)>"
+# Generate a simple changelog template
+cat <<EOF > debian/changelog
+linux ($version) unstable; urgency=low
+
+  * A standard release
+
+ -- $name  $(date -R)
+EOF
+
+# Generate a control file
+cat <<EOF > debian/control
+Source: linux
+Section: base
+Priority: optional
+Maintainer: $name
+Standards-Version: 3.6.1
+
+Package: linux-$version
+Architecture: any
+Description: Linux kernel, version $version
+ This package contains the Linux kernel, modules and corresponding other
+ files version $version.
+EOF
+
+# Fix some ownership and permissions
+chown -R root:root "$tmpdir"
+chmod -R go-w "$tmpdir"
+
+# Perform the final magic
+dpkg-gencontrol -isp
+dpkg --build "$tmpdir" ..
+
+exit 0
+

Re: [PATCH 3/5] kbuild: add deb-pkg target

[Wichert Akkerman]

Previously Sam Ravnborg wrote:
> +# Deb target
> +# ---------------------------------------------------------------------------
> +# 
> +.PHONY: rpm-pkg rpm
> +deb-pkg:

Shouldn't that .PHONY reference deb-pkg instead?

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: [PATCH 3/5] kbuild: add deb-pkg target

[Sam Ravnborg]

On Mon, Jun 14, 2004 at 10:58:27PM +0200, Wichert Akkerman wrote:
> Previously Sam Ravnborg wrote:
> > +# Deb target
> > +# ---------------------------------------------------------------------------
> > +# 
> > +.PHONY: rpm-pkg rpm
> > +deb-pkg:
> 
> Shouldn't that .PHONY reference deb-pkg instead?

Obviously - thanks.
Fixed patch below.

	Sam


# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 21:44:27+02:00 sam@mars.ravnborg.org 
#   kbuild: Added deb target
#   
#   Script originally from Wichert Akkerman <wichert@wiggy.net>
#   Modified to support multiple architectures.
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# scripts/package/builddeb
#   2004/06/14 21:44:12+02:00 sam@mars.ravnborg.org +79 -0
# 
# scripts/package/builddeb
#   2004/06/14 21:44:12+02:00 sam@mars.ravnborg.org +0 -0
#   BitKeeper file /home/sam/bk/kbuild/scripts/package/builddeb
# 
# scripts/package/Makefile
#   2004/06/14 21:44:12+02:00 sam@mars.ravnborg.org +13 -1
#   Added deb-pkg target
# 
diff -Nru a/scripts/package/Makefile b/scripts/package/Makefile
--- a/scripts/package/Makefile	2004-06-14 22:25:41 +02:00
+++ b/scripts/package/Makefile	2004-06-14 22:25:41 +02:00
@@ -46,10 +46,22 @@
 	$(RPM) --target $(UTS_MACHINE) -ta ../$(KERNELPATH).tar.gz
 	rm ../$(KERNELPATH).tar.gz
 
-clean-rule +=  rm $(objtree)/kernel.spec
+clean-rule +=  rm -f $(objtree)/kernel.spec
+
+# Deb target
+# ---------------------------------------------------------------------------
+# 
+.PHONY: deb-pkg
+deb-pkg:
+	@$(MAKE)
+	@$(CONFIG_SHELL) $(srctree)/scripts/package/builddeb
+
+clean-rule += && rm -rf debian/
+
 
 # Help text displayed when executing 'make help'
 # ---------------------------------------------------------------------------
 help:
 	@echo  '  rpm-pkg         - Build the kernel as an RPM package'
+	@echo  '  deb-pkg         - Build the kernel as an deb package'
 
diff -Nru a/scripts/package/builddeb b/scripts/package/builddeb
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/package/builddeb	2004-06-14 22:25:41 +02:00
@@ -0,0 +1,79 @@
+#!/bin/sh
+#
+# builddeb 1.2
+# Copyright 2003 Wichert Akkerman <wichert@wiggy.net>
+#
+# Simple script to generate a deb package for a Linux kernel. All the
+# complexity of what to do with a kernel after it is installer or removed
+# is left to other scripts and packages: they can install scripts in the
+# /etc/kernel/{pre,post}{inst,rm}.d/ directories that will be called on 
+# package install and removal.
+
+set -e
+
+# Some variables and settings used throughout the script
+version="$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
+tmpdir="$(pwd)/debian/tmp"
+
+# Setup the directory structure
+rm -rf "$tmpdir"
+mkdir -p "$tmpdir/DEBIAN" "$tmpdir/lib" "$tmpdir/boot"
+
+# Build and install the kernel
+cp System.map "$tmpdir/boot/System.map-$version"
+cp .config "$tmpdir/boot/config-$version"
+cp $KERNEL_IMAGE "$tmpdir/boot/vmlinuz-$version"
+
+if grep -q '^CONFIG_MODULES=y' .config ; then
+	INSTALL_MOD_PATH="$tmpdir" make modules_install
+fi
+
+# Install the maintainer scripts
+for script in postinst postrm preinst prerm ; do
+	mkdir -p "$tmpdir/etc/kernel/$script.d"
+	cat <<EOF > "$tmpdir/DEBIAN/$script"
+#!/bin/sh
+
+set -e
+
+test -d /etc/kernel/$script.d && run-parts --arg="$version" /etc/kernel/$script.d
+exit 0
+EOF
+	chmod 755 "$tmpdir/DEBIAN/$script"
+done
+
+name="Kernel Compiler <$(id -nu)@$(hostname -f)>"
+# Generate a simple changelog template
+cat <<EOF > debian/changelog
+linux ($version) unstable; urgency=low
+
+  * A standard release
+
+ -- $name  $(date -R)
+EOF
+
+# Generate a control file
+cat <<EOF > debian/control
+Source: linux
+Section: base
+Priority: optional
+Maintainer: $name
+Standards-Version: 3.6.1
+
+Package: linux-$version
+Architecture: any
+Description: Linux kernel, version $version
+ This package contains the Linux kernel, modules and corresponding other
+ files version $version.
+EOF
+
+# Fix some ownership and permissions
+chown -R root:root "$tmpdir"
+chmod -R go-w "$tmpdir"
+
+# Perform the final magic
+dpkg-gencontrol -isp
+dpkg --build "$tmpdir" ..
+
+exit 0
+

Re: [PATCH 4/5] kbuild: make clean improved

[Sam Ravnborg]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 22:09:53+02:00 sam@mars.ravnborg.org 
#   kbuild: make clean deletes a few more unneeded files
#   
#   Make clean shall leave behind only what is needed to build
#   external modules. A few more files can be deleted and modules may still be
#   build successfully.
#   Originally noticed by Andreas Gruenbach
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# Makefile
#   2004/06/14 22:09:39+02:00 sam@mars.ravnborg.org +2 -2
#   kbuild: make clean deletes a few more unneeded files
#   
#   Make clean shall leave behind only what is needed to build
#   external modules. A few more files can be deleted and modules may still be
#   build successfully.
#   Originally noticed by Andreas Gruenbach
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
diff -Nru a/Makefile b/Makefile
--- a/Makefile	2004-06-14 22:25:31 +02:00
+++ b/Makefile	2004-06-14 22:25:31 +02:00
@@ -796,12 +796,12 @@
 
 # Directories & files removed with 'make clean'
 CLEAN_DIRS  += $(MODVERDIR)
-CLEAN_FILES +=	vmlinux System.map \
+CLEAN_FILES +=	vmlinux System.map .version .config.old \
                 .tmp_kallsyms* .tmp_version .tmp_vmlinux*
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include2
-MRPROPER_FILES += .config .config.old include/asm .version \
+MRPROPER_FILES += .config include/asm \
                   include/linux/autoconf.h include/linux/version.h \
                   Module.symvers tags TAGS cscope*
 

Re: [PATCH 4/5] kbuild: make clean improved

[Russell King]

On Mon, Jun 14, 2004 at 10:46:55PM +0200, Sam Ravnborg wrote:
>  # Directories & files removed with 'make clean'
>  CLEAN_DIRS  += $(MODVERDIR)
> -CLEAN_FILES +=	vmlinux System.map \
> +CLEAN_FILES +=	vmlinux System.map .version .config.old \
>                  .tmp_kallsyms* .tmp_version .tmp_vmlinux*

Why should 'make clean' remove the build version?  Traditionally,
this has been preserved until 'make mrproper'.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 4/5] kbuild: make clean improved

[Sam Ravnborg]

On Mon, Jun 14, 2004 at 09:50:34PM +0100, Russell King wrote:
> On Mon, Jun 14, 2004 at 10:46:55PM +0200, Sam Ravnborg wrote:
> >  # Directories & files removed with 'make clean'
> >  CLEAN_DIRS  += $(MODVERDIR)
> > -CLEAN_FILES +=	vmlinux System.map \
> > +CLEAN_FILES +=	vmlinux System.map .version .config.old \
> >                  .tmp_kallsyms* .tmp_version .tmp_vmlinux*
> 
> Why should 'make clean' remove the build version?  Traditionally,
> this has been preserved until 'make mrproper'.

In the 2.4 days people had to do 'make clean' very often.
For the 2.6 kernel this is no longer needed, so when cleaning up
we want to be effective.

.version only really pays off when doing a lot of consecutive
build on the _same_ kernel src.

And make clean is often used in combination with kernel patching,
especially when renaming files: mv mm/slab.c.old mm/slab.c for example.

Here we start over with some new src, so it make sense to start over
with the version?

	Sam

Re: [PATCH 4/5] kbuild: make clean improved

[Tom Rini]

On Mon, Jun 14, 2004 at 11:19:40PM +0200, Sam Ravnborg wrote:
> On Mon, Jun 14, 2004 at 09:50:34PM +0100, Russell King wrote:
> > On Mon, Jun 14, 2004 at 10:46:55PM +0200, Sam Ravnborg wrote:
> > >  # Directories & files removed with 'make clean'
> > >  CLEAN_DIRS  += $(MODVERDIR)
> > > -CLEAN_FILES +=	vmlinux System.map \
> > > +CLEAN_FILES +=	vmlinux System.map .version .config.old \
> > >                  .tmp_kallsyms* .tmp_version .tmp_vmlinux*
> > 
> > Why should 'make clean' remove the build version?  Traditionally,
> > this has been preserved until 'make mrproper'.
> 
> In the 2.4 days people had to do 'make clean' very often.
> For the 2.6 kernel this is no longer needed, so when cleaning up
> we want to be effective.
> 
> .version only really pays off when doing a lot of consecutive
> build on the _same_ kernel src.
> 
> And make clean is often used in combination with kernel patching,
> especially when renaming files: mv mm/slab.c.old mm/slab.c for example.
> 
> Here we start over with some new src, so it make sense to start over
> with the version?

I'd agrue the exact opposite.  If you're starting from scratch (new
patchset, etc, where you might do something like mv mm/slab.c.old
mm/slab.c) use 'distclean' or 'mrproper'.  If you just want to do a
'make clean' because you can't be sure you trust the build system to get
things right, you don't want the version being reset.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 4/5] kbuild: make clean improved

[Sam Ravnborg]

On Mon, Jun 14, 2004 at 02:38:35PM -0700, Tom Rini wrote:
> 
> I'd agrue the exact opposite.  If you're starting from scratch (new
> patchset, etc, where you might do something like mv mm/slab.c.old
> mm/slab.c) use 'distclean' or 'mrproper'.  If you just want to do a
> 'make clean' because you can't be sure you trust the build system to get
> things right, you don't want the version being reset.

I follow both Russell's and your points.
So let's stick to the historic behaviour then.
Updated hand-edited patch below.

	Sam

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 22:09:53+02:00 sam@mars.ravnborg.org 
#   kbuild: make clean deletes a few more unneeded files
#   
#   Make clean shall leave behind only what is needed to build
#   external modules. A few more files can be deleted and modules may still be
#   build successfully.
#   Originally noticed by Andreas Gruenbach
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# Makefile
#   2004/06/14 22:09:39+02:00 sam@mars.ravnborg.org +2 -2
#   kbuild: make clean deletes a few more unneeded files
#   
#   Make clean shall leave behind only what is needed to build
#   external modules. A few more files can be deleted and modules may still be
#   build successfully.
#   Originally noticed by Andreas Gruenbach
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
diff -Nru a/Makefile b/Makefile
--- a/Makefile	2004-06-14 22:25:31 +02:00
+++ b/Makefile	2004-06-14 22:25:31 +02:00
@@ -796,12 +796,12 @@
 
 # Directories & files removed with 'make clean'
 CLEAN_DIRS  += $(MODVERDIR)
-CLEAN_FILES +=	vmlinux System.map \
+CLEAN_FILES +=	vmlinux System.map .config.old \
                 .tmp_kallsyms* .tmp_version .tmp_vmlinux*
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include2
-MRPROPER_FILES += .config .config.old include/asm \
+MRPROPER_FILES += .config include/asm .version \
                   include/linux/autoconf.h include/linux/version.h \
                   Module.symvers tags TAGS cscope*
 

Re: [PATCH 4/5] kbuild: make clean improved

[V13]

On Monday 14 June 2004 23:50, Russell King wrote:
> On Mon, Jun 14, 2004 at 10:46:55PM +0200, Sam Ravnborg wrote:
> >  # Directories & files removed with 'make clean'
> >  CLEAN_DIRS  += $(MODVERDIR)
> > -CLEAN_FILES +=	vmlinux System.map \
> > +CLEAN_FILES +=	vmlinux System.map .version .config.old \
> >                  .tmp_kallsyms* .tmp_version .tmp_vmlinux*
>
> Why should 'make clean' remove the build version?  Traditionally,
> this has been preserved until 'make mrproper'.

I believe that when removing .version you should remove .config too, so either 
it should include .config or it should not include .version.

<<V13>>

Re: [PATCH 5/5] kbuild: external module build doc

[Sam Ravnborg]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 22:21:46+02:00 sam@mars.ravnborg.org 
#   kbuild: Add external module documentation
#   
#   Add first version of a document describing how to build external modules.
#   This is not yet finished, but includes information that is nice to have
#   documented in the kernel even in a less complete form.
#   
#   Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
# 
# Documentation/kbuild/extmodules.txt
#   2004/06/14 22:21:32+02:00 sam@mars.ravnborg.org +168 -0
# 
# Documentation/kbuild/extmodules.txt
#   2004/06/14 22:21:32+02:00 sam@mars.ravnborg.org +0 -0
#   BitKeeper file /home/sam/bk/kbuild/Documentation/kbuild/extmodules.txt
# 
# Documentation/kbuild/00-INDEX
#   2004/06/14 22:21:32+02:00 sam@mars.ravnborg.org +2 -0
#   Added extmodules.txt
# 
diff -Nru a/Documentation/kbuild/00-INDEX b/Documentation/kbuild/00-INDEX
--- a/Documentation/kbuild/00-INDEX	2004-06-14 22:25:21 +02:00
+++ b/Documentation/kbuild/00-INDEX	2004-06-14 22:25:21 +02:00
@@ -6,3 +6,5 @@
 	- developer information for linux kernel makefiles
 modules.txt
 	- how to build modules and to install them
+extmodules.txt
+	- specific information about external modules
diff -Nru a/Documentation/kbuild/extmodules.txt b/Documentation/kbuild/extmodules.txt
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/Documentation/kbuild/extmodules.txt	2004-06-14 22:25:21 +02:00
@@ -0,0 +1,168 @@
+Building external modules
+=========================
+kbuild offers functionality to build external modules, with the
+prerequisite that there is a pre-built kernel avialable with full source.
+A subset of the targets available when building the kernel is available
+when building an external module.
+
+
+Building the module
+-------------------
+The command looks like his:
+
+	make -C <path to kernel src> M=`pwd`
+
+For the above command to succeed the kernel must have been built with
+modules enabled.
+
+To install the modules just being built:
+
+	make -C <path to kernel src> M=`pwd` modules_install
+
+More complex examples later, the above should get you going in most cases.
+
+
+Available targets
+- - - - - - - - - 
+$KDIR refer to path to kernel src
+
+make -C $KDIR M=`pwd`
+	Will build the module(s) located in current directory. All output
+	files will be located in the same directory as the module source.
+	No attemps are made to update the kernel source, and it is
+	expected that a successfully make has been executed
+	for the kernel.
+
+make -C $KDIR M=`pwd` modules
+	Same as if no target was specified. See description above.
+
+make -C $KDIR M=$PWD modules_install
+	Install the external module(s)
+
+make -C $KDIR M=$PWD clean
+	Remove all generated files in for the module - not the kernel
+
+make -C $KDIR M=`pwd` help
+	help will list the available target when building external
+	modules.
+
+Available options:
+- - - - - - - - - 
+$KDIR refer to path to kernel src
+
+make -C $KDIR
+	Used to specify where to find the kernel source.
+	'$KDIR' represent the directory where the kernel source is.
+	Make will actually change directory to the specified directory
+	when executed but change back when finished.
+
+make -C $KDIR M=`pwd`
+	M= is used to tell kbuild that an external module is being built.
+	The option given to M= is the directory where the external
+	module is located.
+	When an external module is being built only a subset of the
+	usual targets are avialable.
+
+make -C $KDIR SUBDIRS=`pwd`
+	Same as M=. The SUBDIRS= syntax is kept for backwards compatibility.
+
+
+A more advanced example
+- - - - - - - - - - - -
+This example shows a setup where a distribution has wisely decided
+to separate kernel source and output files:
+
+Kernel src:
+/usr/src/linux-<kernel-version>/
+
+Output from a kernel compile, including .config:
+/lib/modules/linux-<kernel-version>/build/
+
+External module to be compiled:
+/home/user/module/src/
+
+To compile the module located in the directory above use the
+following command:
+
+	cd /home/user/module/src
+	make -C /usr/src/linux-<kernel-version> \
+	O=/lib/modules/linux-<kernel-version>/build \
+	M=`pwd`
+
+Then to install the module use the following command:
+
+	make -C /usr/src/linux-<kernel-version> \
+		O=/lib/modules/linux-<kernel-version>/build \
+		M='pwd` modules_install
+
+The above are rather long commands, and the following chapter
+lists a few tricks to make it all easier.
+
+Tricks to make it easy
+---------------------
+TODO: .... This need to be rewritten......
+
+A make line with several parameters becomes tiresome and errorprone
+and what follows here is a little trick to make it possible to build
+a module only using a single 'make' command.
+
+Create a makefile named 'Makefile' with the following content:
+---> Makefile:
+
+all:
+	$(MAKE) -C /home/sam/src/kernel/v2.6 M=`pwd` \
+			$(filter-out all,$(MAKECMDGOALS))
+
+obj-m := module.o
+---> End of Makefile
+
+When make is invoked it will see the all: rule, and simply call make again with the right parameters.
+
+If a driver is being developed that is targeted for inclusion in the main kernel, an idea is to seperate out the all: rule to a Makefile nemed makefile (lower capital m) like this:
+
+---> makefile
+all:
+	$(MAKE) -f Makefile -C /home/sam/src/kernel/v2.6 \
+	        M=$(PWD) $(MAKECMDGOALS)
+
+---> End of makefile
+
+The kbuild makefile will include only a single statement:
+---> Makefile:
+
+obj-m := module.o
+
+---> End of Makefile
+When executing make, it looks for a file named makefile, before a
+file named Makefile. Therefor make will pick up the file named with lower capital 'm'.
+
+
+Prepare the kernel for building external modules
+------------------------------------------------
+When building external modules the kernel is expected to be prepared.
+This includes the precense of certain binaries, the kernel configuration
+and the symlink to include/asm.
+To do this a convinient target is made:
+
+	make modules_prepare
+
+For a typical distribution this would look like the follwoing:
+
+	make modules_prepare O=/lib/modules/linux-<kernel version>/build
+
+
+TODO: Fill out the following chapters
+
+Module versioning
+-----------------
+
+Include files targeted towards kernel include/...
+-------------------------------------------------
+
+Local include files
+-------------------
+
+Binary only .o files
+--------------------
+Use _shipped.
+

Re: [PATCH 5/5] kbuild: external module build doc

[Horst von Brand]

Sam Ravnborg <sam@ravnborg.org> said:
> # This is a BitKeeper generated diff -Nru style patch.
> #
> # ChangeSet
> #   2004/06/14 22:21:46+02:00 sam@mars.ravnborg.org 

[...]

> --- /dev/null	Wed Dec 31 16:00:00 196900
> +++ b/Documentation/kbuild/extmodules.txt	2004-06-14 22:25:21 +02:00
> @@ -0,0 +1,168 @@
> +Building external modules
> +=========================
> +kbuild offers functionality to build external modules, with the
> +prerequisite that there is a pre-built kernel avialable with full source.

No. It should be enough to have run "make modules_prepare".

> +A subset of the targets available when building the kernel is available
> +when building an external module.
> +
> +
> +Building the module
> +-------------------
> +The command looks like his:
> +
> +	make -C <path to kernel src> M=`pwd`

For me, it works with:

  make -C <path to kernel src> SUBDIRS=<path to module source> modules
     # Builds
  make -C <path to kernel src> SUBDIRS=<path to module source> modules_install
     # Installs

Besides, IMHO this belongs in Documentation/kbuild/modules.txt.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [PATCH 5/5] kbuild: external module build doc

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 08:13:39AM -0400, Horst von Brand wrote:
> > +Building external modules
> > +=========================
> > +kbuild offers functionality to build external modules, with the
> > +prerequisite that there is a pre-built kernel avialable with full source.
> 
> No. It should be enough to have run "make modules_prepare".

Correct - it was written some time ago.
I will fix.

> > +A subset of the targets available when building the kernel is available
> > +when building an external module.
> > +
> > +
> > +Building the module
> > +-------------------
> > +The command looks like his:
> > +
> > +	make -C <path to kernel src> M=`pwd`
> 
> For me, it works with:
> 
>   make -C <path to kernel src> SUBDIRS=<path to module source> modules
>      # Builds

Today the modules target is not needed, and SUBDIRS= is equivalent to M=
The M= is more in line with other commandline specifiers, therefore documented.
SUBDIRS= will stay for a long time.


>   make -C <path to kernel src> SUBDIRS=<path to module source> modules_install
>      # Installs
> 
> Besides, IMHO this belongs in Documentation/kbuild/modules.txt.

They will be merged when I'm in documentation mode - if noone beats me.

	Sam

Re: [PATCH 5/5] kbuild: external module build doc

[Jari Ruusu]

Sam Ravnborg wrote:
> --- /dev/null   Wed Dec 31 16:00:00 196900
> +++ b/Documentation/kbuild/extmodules.txt       2004-06-14 22:25:21 +02:00
[snip]
> +A more advanced example
> +- - - - - - - - - - - -
> +This example shows a setup where a distribution has wisely decided
> +to separate kernel source and output files:
> +
> +Kernel src:
> +/usr/src/linux-<kernel-version>/
> +
> +Output from a kernel compile, including .config:
> +/lib/modules/linux-<kernel-version>/build/
                                       ^^^^^
Wrong! The 'build' symlink has always pointed to kernel source dir in
separate source and object directory case. Maybe you meant:

Output from a kernel compile, including .config:
/lib/modules/linux-<kernel-version>/object/
                                    ^^^^^^
> +External module to be compiled:
> +/home/user/module/src/
> +
> +To compile the module located in the directory above use the
> +following command:
> +
> +       cd /home/user/module/src
> +       make -C /usr/src/linux-<kernel-version> \
> +       O=/lib/modules/linux-<kernel-version>/build \
                                                ^^^^^
O=/lib/modules/linux-<kernel-version>/object
                                      ^^^^^^
> +       M=`pwd`
> +
> +Then to install the module use the following command:
> +
> +       make -C /usr/src/linux-<kernel-version> \
> +               O=/lib/modules/linux-<kernel-version>/build \
                                                        ^^^^^
O=/lib/modules/linux-<kernel-version>/object
                                      ^^^^^^
> +               M='pwd` modules_install
[snip]
> +Prepare the kernel for building external modules
> +------------------------------------------------
> +When building external modules the kernel is expected to be prepared.
> +This includes the precense of certain binaries, the kernel configuration
> +and the symlink to include/asm.
> +To do this a convinient target is made:
> +
> +       make modules_prepare
> +
> +For a typical distribution this would look like the follwoing:
> +
> +       make modules_prepare O=/lib/modules/linux-<kernel version>/build
                                                                     ^^^^^
make modules_prepare O=/lib/modules/linux-<kernel version>/object
                                                           ^^^^^^
Sam, You don't seem to have any idea how much breakage you introduce if you
insist on redirecting the 'build' symlink from source tree to object tree.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: [PATCH 5/5] kbuild: external module build doc

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 10:21:44PM +0300, Jari Ruusu wrote:
> Sam Ravnborg wrote:
> > --- /dev/null   Wed Dec 31 16:00:00 196900
> > +++ b/Documentation/kbuild/extmodules.txt       2004-06-14 22:25:21 +02:00
> [snip]
> > +A more advanced example
> > +- - - - - - - - - - - -
> > +This example shows a setup where a distribution has wisely decided
> > +to separate kernel source and output files:
> > +
> > +Kernel src:
> > +/usr/src/linux-<kernel-version>/
> > +
> > +Output from a kernel compile, including .config:
> > +/lib/modules/linux-<kernel-version>/build/
>                                        ^^^^^
> Wrong! The 'build' symlink has always pointed to kernel source dir in
> separate source and object directory case.

This document was written before Andreas posted his patch - I just never
came around updating it.
                                                            ^^^^^^
> Sam, You don't seem to have any idea how much breakage you introduce if you
> insist on redirecting the 'build' symlink from source tree to object tree.

No - and I still do not see it. Please explain how we can be backward
compatible when vendors start utilising separate directories for src and output.

Anyway, after I gave it some extra thoughs I concluded that
/lib/modules/kernel-<version>/ was the wrong place to keep
info about where to src for a given build is located.
This information has to stay in the output directory.

So what I will implement is that during the kernel build process
(not the install part) a symlink named 'source' is placed
in the root of the output directory - and links to the root of
the kernel src used for building the kernel.

Then /lib/modules/kernel-<version>/build/source will be where
the source is located.
And /lib/modules/kernel-<version>/build will point to the output files.

If the vendor does not utilise separate src and output directories
they will point to the same directory.
If the vendor utilises separate output and source directories
then thay will point in two different places.

Comments?

	Sam

Re: [PATCH 5/5] kbuild: external module build doc

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

On Tue, 2004-06-15 at 21:55, Sam Ravnborg wrote:

> > Sam, You don't seem to have any idea how much breakage you introduce if you
> > insist on redirecting the 'build' symlink from source tree to object tree.
> 
> No - and I still do not see it. Please explain how we can be backward
> compatible when vendors start utilising separate directories for src and output.
> 
> Anyway, after I gave it some extra thoughs I concluded that
> /lib/modules/kernel-<version>/ was the wrong place to keep
> info about where to src for a given build is located.
> This information has to stay in the output directory.
> 
> So what I will implement is that during the kernel build process
> (not the install part) a symlink named 'source' is placed
> in the root of the output directory - and links to the root of
> the kernel src used for building the kernel.
> 
> Then /lib/modules/kernel-<version>/build/source will be where
> the source is located.
> And /lib/modules/kernel-<version>/build will point to the output files.
> 
> If the vendor does not utilise separate src and output directories
> they will point to the same directory.
> If the vendor utilises separate output and source directories
> then thay will point in two different places.
> 

Please have a look at any package out there (or 99% of them) that need
to figure out where the kernel _source_ is ... they all use something
like:

KERNEL_SRC="/lib/modules/`uname -r`/build"

or

KERNEL_SRC="$(readlink /lib/modules/`uname -r`/build)"

If you now change it to /lib/modules/`uname -r`/build/source, many will
break (depending if they might try things like looking if /usr/src/linux
is around), and all will have to add _another_ kludge to figure things
out.

Its a bad idea IMHO.


Cheers,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/5] kbuild: external module build doc

[Jari Ruusu]

Sam Ravnborg wrote:
> On Tue, Jun 15, 2004 at 10:21:44PM +0300, Jari Ruusu wrote:
> > Sam, You don't seem to have any idea how much breakage you introduce if you
> > insist on redirecting the 'build' symlink from source tree to object tree.
> 
> No - and I still do not see it.

If you don't understand how many external packages depend on the 'build'
symlink pointing to directory where toplevel kernel Makefile is, then may I
suggest that you do NOT touch that symlink all.

> Please explain how we can be backward
> compatible when vendors start utilising separate directories for src and output.

Most backward compatible way is to leave the 'build' symlink alone, and add
another /lib/modules/`uname -r`/object symlink that points to the object
tree.

> Anyway, after I gave it some extra thoughs I concluded that
> /lib/modules/kernel-<version>/ was the wrong place to keep
> info about where to src for a given build is located.
> This information has to stay in the output directory.

Why can't there be two symlinks?

We have one now (the 'build' symlink) that points to the build machinery,
and adding another (the 'object' symlink) that points to object tree is no
big deal.

> So what I will implement is that during the kernel build process
> (not the install part) a symlink named 'source' is placed
> in the root of the output directory - and links to the root of
> the kernel src used for building the kernel.
> 
> Then /lib/modules/kernel-<version>/build/source will be where

Nobody gave me a veto right, but I yell VETO now!

> the source is located.
> And /lib/modules/kernel-<version>/build will point to the output files.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Mon, Jun 14, 2004 at 10:40:29PM +0200, Sam Ravnborg wrote:
> 
> 
> Above changes can be pulled from linux-sam.bkbits.net/kbuild:
> bk pull bk://linux-sam.bkbits.net/kbuild
> (Being updated as I type)

I've had some disk problems lately. And this seems to have hit my bk repo.
So the patchtes are not pullable - sorry.

	Sam

Re: [PATCH 0/5] kbuild

[Jeff Garzik]

Sam Ravnborg wrote:
> default kernel image:		Specify default target at config
> 				time rather then hardcode it.
> 				Only enabled for i386 for now.


> external module build doc:	Add documentation for building external modules


I like these two especially.  Thanks much,

	Jeff

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Mon, Jun 14, 2004 at 10:40:29PM +0200, Sam Ravnborg wrote:

> Hi Andrew. Here follows a number of kbuild patches.
> 
> The first replaces kbuild-specify-default-target-during-configuration.patch
> 
> They have seen ligiht testing here, but on the other hand the do not touch
> any critical part of kbuild.
> 
> Patches:
> 
> default kernel image:		Specify default target at config
> 				time rather then hardcode it.
> 				Only enabled for i386 for now.

While I'd guess this is better than the patch it's replacing, given that
most i386 kernels are 'bzImage', what's wrong with the current logic
that picks out what to do for the all target now?

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 08:41:36AM -0700, Tom Rini wrote:
> On Mon, Jun 14, 2004 at 10:40:29PM +0200, Sam Ravnborg wrote:
> 
> > Hi Andrew. Here follows a number of kbuild patches.
> > 
> > The first replaces kbuild-specify-default-target-during-configuration.patch
> > 
> > They have seen ligiht testing here, but on the other hand the do not touch
> > any critical part of kbuild.
> > 
> > Patches:
> > 
> > default kernel image:		Specify default target at config
> > 				time rather then hardcode it.
> > 				Only enabled for i386 for now.
> 
> While I'd guess this is better than the patch it's replacing, given that
> most i386 kernels are 'bzImage', what's wrong with the current logic
> that picks out what to do for the all target now?

Compared to the original behaviour where the all: target picked the default
target for a given architecture, this patch adds the following:

- One has to select the default kernel image only once
  when configuring the kernel.
- There exist a possibility to add more than half a line of text
  describing individual targets. All relevant information can be
  specified in the help section in the Kconfig file
- Other programs now have access to what kernel image has been built.
  This is needed when creating kernel packages like rpm.

Where I see this really pay off is for architectures like MIPS with
at least four different targets, depending on selected config.
When one has selected to build a certain kernel, including a specific
bootloader only the make command is needed.
No need to remember the 'make rom.bin' or whatever target.

But this trigger the discussion how much should actually be
part of the kernel.
Building a kernel, storing it on target, and starting the kernel
should be a simple process.
>From this the current behaviour seems good:
$ make
$ copy image
$ reset the board (reset PC whatever)

If we remove the current support for for example uboot we create an
additional step in between the make and copy image.

What is the problem today is more the lack of infrastructure
support for different kernel images.
And this is where we should concentrate.

	Sam

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Tue, Jun 15, 2004 at 07:49:29PM +0200, Sam Ravnborg wrote:

> On Tue, Jun 15, 2004 at 08:41:36AM -0700, Tom Rini wrote:
> > On Mon, Jun 14, 2004 at 10:40:29PM +0200, Sam Ravnborg wrote:
> > 
> > > Hi Andrew. Here follows a number of kbuild patches.
> > > 
> > > The first replaces kbuild-specify-default-target-during-configuration.patch
> > > 
> > > They have seen ligiht testing here, but on the other hand the do not touch
> > > any critical part of kbuild.
> > > 
> > > Patches:
> > > 
> > > default kernel image:		Specify default target at config
> > > 				time rather then hardcode it.
> > > 				Only enabled for i386 for now.
> > 
> > While I'd guess this is better than the patch it's replacing, given that
> > most i386 kernels are 'bzImage', what's wrong with the current logic
> > that picks out what to do for the all target now?
> 
> Compared to the original behaviour where the all: target picked the default
> target for a given architecture, this patch adds the following:
> 
> - One has to select the default kernel image only once
>   when configuring the kernel.

in the case where 'all' wasn't correct to start with.  And i386 isn't
the convincing case here.

> - There exist a possibility to add more than half a line of text
>   describing individual targets. All relevant information can be
>   specified in the help section in the Kconfig file

Honestly, I'm indifferent to this.  This problem is equally, if not
better solved by documenting in the board-specific help "and use 'make
fooImage for foo firmware"

> - Other programs now have access to what kernel image has been built.
>   This is needed when creating kernel packages like rpm.

I suppose this can clean up some of the globbing that might otherwise be
done, but I know for a fact that there's been kernel rpms before this :)

> Where I see this really pay off is for architectures like MIPS with
> at least four different targets, depending on selected config.
> When one has selected to build a certain kernel, including a specific
> bootloader only the make command is needed.
> No need to remember the 'make rom.bin' or whatever target.

This is where I see it blowing up, quite badly.  As Russell noted,
you're going to have a horrible, unmaintainable list of boards and
firmware supported, or not, on each.  Even on PPC32 where we really only
have "needs vmlinux, raw", "needs vmlinux, for U-Boot" and "can use
arch/ppc/boot/", it'll still get ugly noting which boards can use
U-Boot, which can use arch/ppc/boot/ and which can use both.

> But this trigger the discussion how much should actually be
> part of the kernel.

Yes, there's that another discussion, which at least I'm not talking
about right now.  What I, and I think Russell as well, are noting is
that doing this is will make what we have in the kernel much uglier /
less maintainable.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 10:54:53AM -0700, Tom Rini wrote:
> > 
> > - One has to select the default kernel image only once
> >   when configuring the kernel.
> 
> in the case where 'all' wasn't correct to start with.  And i386 isn't
> the convincing case here.
If all was correct in first place this patch does not change behaviour.
For the embedded space all: is often not the right choice,
but for i386 (as you note) all: is always OK (except some rare cases).

> > - There exist a possibility to add more than half a line of text
> >   describing individual targets. All relevant information can be
> >   specified in the help section in the Kconfig file
> 
> Honestly, I'm indifferent to this.  This problem is equally, if not
> better solved by documenting in the board-specific help "and use 'make
> fooImage for foo firmware"

For ppc I see nowhere documented what znetboot, vmlinux.sm neither
zimage is used for.
In total 5 different kernel targets that is un-documented.
Adding this patch gives you a good way to document
them - and room for it.
For the uimage target, I would at least expect a reference
to the relevant bootloader, and maybe a few notes about
the format as well. But there is not room for it on half a line.
If you know what uImage is, not problem. But for newcomers
wondering what it is - this is relevant.

> 
> > - Other programs now have access to what kernel image has been built.
> >   This is needed when creating kernel packages like rpm.
> 
> I suppose this can clean up some of the globbing that might otherwise be
> done, but I know for a fact that there's been kernel rpms before this :)
Did you actually take a look in the mkspec script?
If ARCH equals i386 select bzImage, otherwise select vmlinux.
Not scalable at all - and this type of information should be part
of the architecture specific files, not the mkspec script.

> 
> > Where I see this really pay off is for architectures like MIPS with
> > at least four different targets, depending on selected config.
> > When one has selected to build a certain kernel, including a specific
> > bootloader only the make command is needed.
> > No need to remember the 'make rom.bin' or whatever target.
> 
> This is where I see it blowing up, quite badly.  As Russell noted,
> you're going to have a horrible, unmaintainable list of boards and
> firmware supported, or not, on each.  Even on PPC32 where we really only
> have "needs vmlinux, raw", "needs vmlinux, for U-Boot" and "can use
> arch/ppc/boot/", it'll still get ugly noting which boards can use
> U-Boot, which can use arch/ppc/boot/ and which can use both.

What the patch does is to create a placeholder for
existing targets. No requirements exist for doing what you propose.
But for a given board I would expect the defconfig to select the correct
kernel image.
So when executing:
make ARCH=ppc FADS_defconfig && make ARCH=ppc CROSS...
Kbuild shall build a kernel that works with the selected board with a
default bootloader.
This would be enabled by FADS_defconfig having CONFIG_KERNEL_IMAGE_ZNETBOOT
selected.

In contrast the walnut board has a sane bootloader that accepts a vmlinux,
so here CONFIG_KERNEL_IMAGE_VMLINUX is selected in defconfig.
[Not knowing the baords in question, just as examples].

In this way the board specific config files select the target
to be build, not the other way around.

	Sam

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Tue, Jun 15, 2004 at 09:01:19PM +0200, Sam Ravnborg wrote:

> On Tue, Jun 15, 2004 at 10:54:53AM -0700, Tom Rini wrote:
> > > 
> > > - One has to select the default kernel image only once
> > >   when configuring the kernel.
> > 
> > in the case where 'all' wasn't correct to start with.  And i386 isn't
> > the convincing case here.
> If all was correct in first place this patch does not change behaviour.
> For the embedded space all: is often not the right choice,

That's quite debatable.  'all' does do the right thing on ppc32.

> but for i386 (as you note) all: is always OK (except some rare cases).
> 
> > > - There exist a possibility to add more than half a line of text
> > >   describing individual targets. All relevant information can be
> > >   specified in the help section in the Kconfig file
> > 
> > Honestly, I'm indifferent to this.  This problem is equally, if not
> > better solved by documenting in the board-specific help "and use 'make
> > fooImage for foo firmware"
> 
> For ppc I see nowhere documented what znetboot, vmlinux.sm neither
> zimage is used for.

True.  A patch to add that bit 'o help to the archhelp target would
happily be reviewed.

> In total 5 different kernel targets that is un-documented.
> Adding this patch gives you a good way to document
> them - and room for it.
> For the uimage target, I would at least expect a reference
> to the relevant bootloader, and maybe a few notes about
> the format as well. But there is not room for it on half a line.
> If you know what uImage is, not problem. But for newcomers
> wondering what it is - this is relevant.

What I don't see is why:
'znetboot - Build a zImage and put into /tftpboot/
 uImage - Build an image for U-Boot
 rom.img - Build an image to live on ROM
 srec - Build an SREC image'

etc, isn't sufficient, in the archhelp.  Especially with a note added to
the boards for the corner cases where all isn't correct (foo-board only
supports U-Boot, so you should use uImage to get things working
directly).

> > > - Other programs now have access to what kernel image has been built.
> > >   This is needed when creating kernel packages like rpm.
> > 
> > I suppose this can clean up some of the globbing that might otherwise be
> > done, but I know for a fact that there's been kernel rpms before this :)
>
> Did you actually take a look in the mkspec script?
> If ARCH equals i386 select bzImage, otherwise select vmlinux.
> Not scalable at all - and this type of information should be part
> of the architecture specific files, not the mkspec script.

Without stepping too much into the what belongs in the kernel debate,
you've already got lots of board-specific things to handle, so if it's
already documented.

> > > Where I see this really pay off is for architectures like MIPS with
> > > at least four different targets, depending on selected config.
> > > When one has selected to build a certain kernel, including a specific
> > > bootloader only the make command is needed.
> > > No need to remember the 'make rom.bin' or whatever target.
> > 
> > This is where I see it blowing up, quite badly.  As Russell noted,
> > you're going to have a horrible, unmaintainable list of boards and
> > firmware supported, or not, on each.  Even on PPC32 where we really only
> > have "needs vmlinux, raw", "needs vmlinux, for U-Boot" and "can use
> > arch/ppc/boot/", it'll still get ugly noting which boards can use
> > U-Boot, which can use arch/ppc/boot/ and which can use both.
> 
> What the patch does is to create a placeholder for
> existing targets. No requirements exist for doing what you propose.

Which gets back to one of Russells points.  You can document the formats
all you want, but that won't help the user pick one, unless they already
know enough to not need this information to start with.

Or, you restrict their choices to what would work, which is a horrible
mess.  And you may need to restrict the choices, otherwise we'll get
'allyesconfig' doesn't build type messages again (yes, I've already had
to re-arrange things once for allyesconfig on ppc32).

> But for a given board I would expect the defconfig to select the correct
> kernel image.

<nit>'correct' is such an odd word here.  Especially in the case where
all of them are valid targets.</nit>

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 12:27:40PM -0700, Tom Rini wrote:
> 
> What I don't see is why:
> 'znetboot - Build a zImage and put into /tftpboot/
>  uImage - Build an image for U-Boot
>  rom.img - Build an image to live on ROM
>  srec - Build an SREC image'
> 
> etc, isn't sufficient, in the archhelp.

Two things.
1) You better remember to specify them each and every time.
   Otherwise uImage gets out of sync with the kernel.
2) I know the srec format, but that is no help to expaling me
   the actual content of the file.
   Memory layout, start address or whatever. Where to find this info.
   Same goes for other targets. I you know your stuff no swaet.
   But for $random hacker it becomes another obstacle

 
> Or, you restrict their choices to what would work, which is a horrible
> mess.  And you may need to restrict the choices, otherwise we'll get
> 'allyesconfig' doesn't build type messages again (yes, I've already had
> to re-arrange things once for allyesconfig on ppc32).
> 
> > But for a given board I would expect the defconfig to select the correct
> > kernel image.
> 
> <nit>'correct' is such an odd word here.  Especially in the case where
> all of them are valid targets.</nit>

Read 'type of'. In most case zImage I assume, but in some case with a
bootloader added. The other options may vary (a lot).

	Sam

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Tue, Jun 15, 2004 at 11:02:40PM +0200, Sam Ravnborg wrote:

> On Tue, Jun 15, 2004 at 12:27:40PM -0700, Tom Rini wrote:
> > 
> > What I don't see is why:
> > 'znetboot - Build a zImage and put into /tftpboot/
> >  uImage - Build an image for U-Boot
> >  rom.img - Build an image to live on ROM
> >  srec - Build an SREC image'
> > 
> > etc, isn't sufficient, in the archhelp.
> 
> Two things.
> 1) You better remember to specify them each and every time.
>    Otherwise uImage gets out of sync with the kernel.

Yes, you better.  If you want the kernel to do a little extra for you,
you need to remember to tell it that.

> 2) I know the srec format, but that is no help to expaling me
>    the actual content of the file.
>    Memory layout, start address or whatever. Where to find this info.
>    Same goes for other targets. I you know your stuff no swaet.
>    But for $random hacker it becomes another obstacle

Let me try this a different way.  The only valid boot targets on ppc32
are:
- zImage (which is what all does)
- znetboot (zImage + copy to /tftpboot/)
- uImage (U-Boot'ify a kernel)

wrt the last one, I'm torn between making it something that always
happens, since it's just so easy, and if it fails, we can just not care
about it (||true it, or something) or just not worry about it, since if
you're using U-Boot most likely you've already flashed it on, and know
what you're doing).

The "pick the right target" mojo done to ppc32 is like doing it on i386,
it's not a good example of what'll be cleaned up.  Same, so it seems,
with ARM.  WRT MIPS, I've pointed Ralf at the thread, and he should
speak up soon, I hope :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Russell King]

On Tue, Jun 15, 2004 at 07:49:29PM +0200, Sam Ravnborg wrote:
> On Tue, Jun 15, 2004 at 08:41:36AM -0700, Tom Rini wrote:
> > On Mon, Jun 14, 2004 at 10:40:29PM +0200, Sam Ravnborg wrote:
> > 
> > > Hi Andrew. Here follows a number of kbuild patches.
> > > 
> > > The first replaces kbuild-specify-default-target-during-configuration.patch
> > > 
> > > They have seen ligiht testing here, but on the other hand the do not touch
> > > any critical part of kbuild.
> > > 
> > > Patches:
> > > 
> > > default kernel image:		Specify default target at config
> > > 				time rather then hardcode it.
> > > 				Only enabled for i386 for now.
> > 
> > While I'd guess this is better than the patch it's replacing, given that
> > most i386 kernels are 'bzImage', what's wrong with the current logic
> > that picks out what to do for the all target now?
> 
> Compared to the original behaviour where the all: target picked the default
> target for a given architecture, this patch adds the following:

This isn't the case on ARM.  I've always told people 'make zImage'
or 'make Image'.  I've never told people to use just 'make' on its
own - in fact, I've never used 'make' on its own with the kernel.

> - One has to select the default kernel image only once
>   when configuring the kernel.
> - There exist a possibility to add more than half a line of text
>   describing individual targets. All relevant information can be
>   specified in the help section in the Kconfig file

You can't fit details for 500 platforms into half a line of text.

> If we remove the current support for for example uboot we create an
> additional step in between the make and copy image.

uboot support on ARM was only recently added, and only happened
because I happened to misread the patch.  Had I been more on the
ball, the support would NOT have been merged.  However, as it did
get merged, I didn't want to create extra noise by taking it out.

Please don't take this as acceptance that throwing the uboot crap
into the kernel for ARM was something I found agreeable.  I still
find it distasteful that boot loaders have to define their own
image formats and the kernel has to conform to the boot loader
authors whims.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 07:09:51PM +0100, Russell King wrote:
> > 
> > Compared to the original behaviour where the all: target picked the default
> > target for a given architecture, this patch adds the following:
> 
> This isn't the case on ARM.  I've always told people 'make zImage'
> or 'make Image'.  I've never told people to use just 'make' on its
> own - in fact, I've never used 'make' on its own with the kernel.

Why not?
Letting the build system select a default target is often a
better choice than some random choice by a developer.

> 
> > - One has to select the default kernel image only once
> >   when configuring the kernel.
> > - There exist a possibility to add more than half a line of text
> >   describing individual targets. All relevant information can be
> >   specified in the help section in the Kconfig file
> 
> You can't fit details for 500 platforms into half a line of text.
Not discussing different platforms, only discussing kernel targets.
For arm I see the following:
zImage, Image bootpImage uImage
And some test targets: zImg, Img, bp, i, zi

Not counting the test targets it is only 4 target of which 3 is
documented in help today.

> 
> > If we remove the current support for for example uboot we create an
> > additional step in between the make and copy image.
> 
> uboot support on ARM was only recently added, and only happened
> because I happened to misread the patch.  Had I been more on the
> ball, the support would NOT have been merged.  However, as it did
> get merged, I didn't want to create extra noise by taking it out.
> 
> Please don't take this as acceptance that throwing the uboot crap
> into the kernel for ARM was something I found agreeable.  I still
> find it distasteful that boot loaders have to define their own
> image formats and the kernel has to conform to the boot loader
> authors whims.

Maybe Wolgang can jump in here - I do not know why mkimage is needed.
But I do like to have it present for convinience.
It is btw called mkuboot.sh in scripts/ to better say what it does.

	Sam

Re: [PATCH 0/5] kbuild

[Russell King]

On Tue, Jun 15, 2004 at 09:14:18PM +0200, Sam Ravnborg wrote:
> On Tue, Jun 15, 2004 at 07:09:51PM +0100, Russell King wrote:
> > > 
> > > Compared to the original behaviour where the all: target picked the default
> > > target for a given architecture, this patch adds the following:
> > 
> > This isn't the case on ARM.  I've always told people 'make zImage'
> > or 'make Image'.  I've never told people to use just 'make' on its
> > own - in fact, I've never used 'make' on its own with the kernel.
> 
> Why not?

It's something we've never done - we've always traditionally told people
to use 'make zImage' or whatever, because then they know what they're
getting.

See: http://www.arm.linux.org.uk/docs/kerncomp.shtml

This works for no matter what kernel version you're building, whether
its pre or post new kbuild.

> Letting the build system select a default target is often a
> better choice than some random choice by a developer.

No.  Only the developer knows what boot loader he's going to use on
the board, he knows what modifications he's made, he knows how he's
configured it.  Therefore he knows full well what he needs from the
kernel.

> Not discussing different platforms, only discussing kernel targets.
> For arm I see the following:
> zImage, Image bootpImage uImage
> And some test targets: zImg, Img, bp, i, zi

For ARM, there are: zImage and Image.  bootpImage is an add-on extra
which requires extra parameters to be passed in order to use - and
is our fix for the day that NFS requires external programs (though
it seems to have been superseded by initramfs now, so will probably
go away soon.)

I'm considering dropping the test targets - they were useful for me
personally back in the days when I wasn't using a script-based kernel
build system.  Now that all my kernel builds are scripted, those
targets aren't used anymore and can go.

That leaves uImage which I've discussed already in a previous mail,
and various other targets which I've historically said I won't merge
(as I detailed in a previous mail - srec, gzipped vmlinux, gzipped
Image, etc.)

> Maybe Wolgang can jump in here - I do not know why mkimage is needed.
> But I do like to have it present for convinience.
> It is btw called mkuboot.sh in scripts/ to better say what it does.

I'll let you read mkuboot.sh - you'll find that it's just a wrapper
script to moan if you use mkuboot.sh and you don't have mkimage
installed.

I've no idea what mkimage actually does, but from the scant comments
in mkuboot.sh, it seems to package up into a "U-Boot image".

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 08:46:16PM +0100, Russell King wrote:
> 
> > Maybe Wolgang can jump in here - I do not know why mkimage is needed.
> > But I do like to have it present for convinience.
> > It is btw called mkuboot.sh in scripts/ to better say what it does.
> 
> I'll let you read mkuboot.sh - you'll find that it's just a wrapper
> script to moan if you use mkuboot.sh and you don't have mkimage
> installed.
> 
> I've no idea what mkimage actually does, but from the scant comments
> in mkuboot.sh, it seems to package up into a "U-Boot image".

I know. I objected to the mkimage name in the past for a script in scripts/
for the same reasons as you outline.

	Sam

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 08:46:16PM +0100, Russell King wrote:
> On Tue, Jun 15, 2004 at 09:14:18PM +0200, Sam Ravnborg wrote:
> > On Tue, Jun 15, 2004 at 07:09:51PM +0100, Russell King wrote:
> > > > 
> > > > Compared to the original behaviour where the all: target picked the default
> > > > target for a given architecture, this patch adds the following:
> > > 
> > > This isn't the case on ARM.  I've always told people 'make zImage'
> > > or 'make Image'.  I've never told people to use just 'make' on its
> > > own - in fact, I've never used 'make' on its own with the kernel.
> > 
> > Why not?
> 
> It's something we've never done - we've always traditionally told people
> to use 'make zImage' or whatever, because then they know what they're
> getting.
> 
> See: http://www.arm.linux.org.uk/docs/kerncomp.shtml
> 
> This works for no matter what kernel version you're building, whether
> its pre or post new kbuild.

Looks good. And for 2.6 no need for two steps "make zImage" and "make modules".
'make' alone will do the job and make sure zImage and modules are consistent.


> 
> > Not discussing different platforms, only discussing kernel targets.
> > For arm I see the following:
> > zImage, Image bootpImage uImage
> > And some test targets: zImg, Img, bp, i, zi
> 
> For ARM, there are: zImage and Image.  bootpImage is an add-on extra
> which requires extra parameters to be passed in order to use - and
> is our fix for the day that NFS requires external programs (though
> it seems to have been superseded by initramfs now, so will probably
> go away soon.)
And here is my point. How to you put this info in less than one line?
So I just see proff that we need to be able to give a bit more info
about the possible targets.
"which requires extra parameters...." is also a sign that more 
info would be nice.
Now I have to read and understand a Makefile to find the info.

> 
> That leaves uImage which I've discussed already in a previous mail,
> and various other targets which I've historically said I won't merge
> (as I detailed in a previous mail - srec, gzipped vmlinux, gzipped
> Image, etc.)
For arm it looks simple, but for ppc the commandline to mkuboot.sh
varies depending on configuration.
Better do this in the kernel.

	Sam

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Tue, Jun 15, 2004 at 10:55:57PM +0200, Sam Ravnborg wrote:
> On Tue, Jun 15, 2004 at 08:46:16PM +0100, Russell King wrote:
> > That leaves uImage which I've discussed already in a previous mail,
> > and various other targets which I've historically said I won't merge
> > (as I detailed in a previous mail - srec, gzipped vmlinux, gzipped
> > Image, etc.)
> For arm it looks simple, but for ppc the commandline to mkuboot.sh
> varies depending on configuration.

No it doesn't.  CONFIG_SHELL doesn't count :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 01:59:58PM -0700, Tom Rini wrote:
> On Tue, Jun 15, 2004 at 10:55:57PM +0200, Sam Ravnborg wrote:
> > On Tue, Jun 15, 2004 at 08:46:16PM +0100, Russell King wrote:
> > > That leaves uImage which I've discussed already in a previous mail,
> > > and various other targets which I've historically said I won't merge
> > > (as I detailed in a previous mail - srec, gzipped vmlinux, gzipped
> > > Image, etc.)
> > For arm it looks simple, but for ppc the commandline to mkuboot.sh
> > varies depending on configuration.
> 
> No it doesn't.  CONFIG_SHELL doesn't count :)

It was the other way around.

>From arm:

      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
                   -C none -a $(ZRELADDR) -e $(ZRELADDR) \
                   -n 'Linux-$(KERNELRELEASE)' -d $< $@

And ZRELADDR varies with configuration, ~20 different values.

	Sam

Re: [PATCH 0/5] kbuild

[Russell King]

On Tue, Jun 15, 2004 at 10:55:57PM +0200, Sam Ravnborg wrote:
> Looks good. And for 2.6 no need for two steps "make zImage" and "make modules".
> 'make' alone will do the job and make sure zImage and modules are consistent.

Correct, however the document is for 2.4 as well so in the interests of
not making things more complex than they have to be, it's easier to
tell people to use the old way.

> > For ARM, there are: zImage and Image.  bootpImage is an add-on extra
> > which requires extra parameters to be passed in order to use - and
> > is our fix for the day that NFS requires external programs (though
> > it seems to have been superseded by initramfs now, so will probably
> > go away soon.)
> And here is my point. How to you put this info in less than one line?
> So I just see proff that we need to be able to give a bit more info
> about the possible targets.
> "which requires extra parameters...." is also a sign that more 
> info would be nice.
> Now I have to read and understand a Makefile to find the info.

If you don't supply INITRD= then the makefile will prompt you for
it.  Ok, the message can be improved, but it does still tell you
what you did wrong.  I also pointed out that this target is legacy
and probably going away soon, so it can't be used to justify a
point.

> > That leaves uImage which I've discussed already in a previous mail,
> > and various other targets which I've historically said I won't merge
> > (as I detailed in a previous mail - srec, gzipped vmlinux, gzipped
> > Image, etc.)
> For arm it looks simple, but for ppc the commandline to mkuboot.sh
> varies depending on configuration.
> Better do this in the kernel.

You seem to have missed my point again, concentrating on uImage only.
Also, I think you got PPC and ARM confused - PPC is simple, but ARM
depends on the kernel configuration.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

What about this much simpler approach?

One extra assignment for each architecture added to get access to the
kernel image (at least the default one) for that architecture.

The sole purpose for this is to pass info what
kernel image should be included in a deb, rpm or tar.gz package.


	Sam

===== arch/arm/Makefile 1.66 vs edited =====
--- 1.66/arch/arm/Makefile	2004-05-12 23:55:05 +02:00
+++ edited/arch/arm/Makefile	2004-06-16 21:47:11 +02:00
@@ -130,6 +130,7 @@
 all: zImage
 
 boot := arch/arm/boot
+KERNEL_IMAGE := $(boot)/zImage
 
 #	Update machine arch and proc symlinks if something which affects
 #	them changed.  We use .arch to indicate when they were updated
===== arch/i386/Makefile 1.68 vs edited =====
--- 1.68/arch/i386/Makefile	2004-06-01 00:18:41 +02:00
+++ edited/arch/i386/Makefile	2004-06-16 21:43:50 +02:00
@@ -120,6 +120,7 @@
 	zdisk bzdisk fdimage fdimage144 fdimage288 install
 
 all: bzImage
+KERNEL_IMAGE := $(boot)/bzImage
 
 BOOTIMAGE=arch/i386/boot/bzImage
 zImage zlilo zdisk: BOOTIMAGE=arch/i386/boot/zImage
===== arch/ppc/Makefile 1.50 vs edited =====
--- 1.50/arch/ppc/Makefile	2004-06-09 10:52:22 +02:00
+++ edited/arch/ppc/Makefile	2004-06-16 21:44:01 +02:00
@@ -49,6 +49,7 @@
 .PHONY: $(BOOT_TARGETS)
 
 all: zImage
+KERNEL_IMAGE := arch/ppc/boot/images/zImage
 
 AFLAGS_vmlinux.lds.o	:= -Upowerpc
 

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Wed, Jun 16, 2004 at 09:49:19PM +0200, Sam Ravnborg wrote:

> What about this much simpler approach?
> 
> One extra assignment for each architecture added to get access to the
> kernel image (at least the default one) for that architecture.

Will it also include the 'vmlinux' ?  And would I be right in assuming
that it will accept (a) globs and (b) can be defined inside of
arch/ppc/boot/foo/Makefile ?

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Wed, Jun 16, 2004 at 01:08:24PM -0700, Tom Rini wrote:
> On Wed, Jun 16, 2004 at 09:49:19PM +0200, Sam Ravnborg wrote:
> 
> > What about this much simpler approach?
> > 
> > One extra assignment for each architecture added to get access to the
> > kernel image (at least the default one) for that architecture.
> 
> Will it also include the 'vmlinux' ?
Today the rpm does not include vmlinux - but thats a trivial thing to add.
I assume the same is tru for .deb
tar.gz is not written yet...

>  And would I be right in assuming
> that it will accept (a) globs and (b) can be defined inside of
> arch/ppc/boot/foo/Makefile ?
Yes, and yes.

	Sam

Re: [PATCH 0/5] kbuild

[Tom Rini]

On Wed, Jun 16, 2004 at 10:54:16PM +0200, Sam Ravnborg wrote:
> On Wed, Jun 16, 2004 at 01:08:24PM -0700, Tom Rini wrote:
> > On Wed, Jun 16, 2004 at 09:49:19PM +0200, Sam Ravnborg wrote:
> > 
> > > What about this much simpler approach?
> > > 
> > > One extra assignment for each architecture added to get access to the
> > > kernel image (at least the default one) for that architecture.
> > 
> > Will it also include the 'vmlinux' ?
> Today the rpm does not include vmlinux - but thats a trivial thing to add.
> I assume the same is tru for .deb
> tar.gz is not written yet...
> 
> >  And would I be right in assuming
> > that it will accept (a) globs and (b) can be defined inside of
> > arch/ppc/boot/foo/Makefile ?
> Yes, and yes.

Then I think I can live with it, and fix it up to be correct on PPC32
once it's in.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH 0/5] kbuild

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Wed, 2004-06-16 22:54:16 +0200, Sam Ravnborg <sam@ravnborg.org>
wrote in message <20040616205415.GA2096@mars.ravnborg.org>:
> On Wed, Jun 16, 2004 at 01:08:24PM -0700, Tom Rini wrote:
> > Will it also include the 'vmlinux' ?
> Today the rpm does not include vmlinux - but thats a trivial thing to add.
> I assume the same is tru for .deb
> tar.gz is not written yet...

I'll take your patches and see how to make a .tar.gz from it.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Thu, Jun 17, 2004 at 08:56:24AM +0200, Jan-Benedict Glaw wrote:
> On Wed, 2004-06-16 22:54:16 +0200, Sam Ravnborg <sam@ravnborg.org>
> wrote in message <20040616205415.GA2096@mars.ravnborg.org>:
> > On Wed, Jun 16, 2004 at 01:08:24PM -0700, Tom Rini wrote:
> > > Will it also include the 'vmlinux' ?
> > Today the rpm does not include vmlinux - but thats a trivial thing to add.
> > I assume the same is tru for .deb
> > tar.gz is not written yet...
> 
> I'll take your patches and see how to make a .tar.gz from it.

Great, thanks.
I will update my patch-set during the weekend if time permits..

	Sam

kbuild: Simplify vmlinux generation

[Sam Ravnborg]

Several new changes pushed out to:
bk://linux-sam.bkbits.net/kbuild

Already posted to lkml:
o Remove last sign of LDFALGS_BLOB (raisorblade)
o Set cflags before including arch Makefile (raisorblade)
o use KERNELREALSE consistently (Brian Gerst)
o Support LOCALVERSION (ianw)

Included as patch in this mail:
o Simplified vmlinux generation

Generating vmlinux in top-level Makefile were getting a bit messy after kallsyms
support were added. Also the full link of all the .o files were duplicaed a number of times.
This patch does the following:
- Introduce built-in.o which is a prelink of most .o files
- Make the build process a bit more verbose telling when linking .tmpvmlinux*
- Use less magic when determing when to generate a new version
- Allow architectures to override the defineition of cmd_vmlinux__
- Add more comments to the MAkefile and clean up soem other comments
- Display more commends during V=1 builds

The resulting kernel boots and run here.


This clear the queue of kbuild modifications to support um.
I expect to see wiedespread use of LOCALVERSION :-)

In my in-queue is mainly pkg patches now.
Current slew of kconfig related patches will go in via Andrew.

	Sam
	
diff -Nru a/Makefile b/Makefile
--- a/Makefile	2004-09-05 22:06:47 +02:00
+++ b/Makefile	2004-09-05 22:06:47 +02:00
@@ -545,67 +545,91 @@
 
 # Build vmlinux
 # ---------------------------------------------------------------------------
+# vmlinux is build from the objects seleted by $(vmlinux-init) and
+# $(vmlinux-main). Most are built-in.o files from top-level directories
+# in the kernel tree, others are specified in arch/$(ARCH)Makefile.
+# Ordering when linking is important, and $(vmlinux-init) must be first.
+#
+# vmlinux
+#   ^
+#   |
+#   +-< $(vmlinux-init)
+#   |   +--< init/version.o + more
+#   |
+#   +-< built-in.o
+#   |   +--< $(vmlinux-main)
+#   |        +--< driver/built-in.o mm/built-in.o + more
+#   |
+#   +-< kallsyms.o (see description in CONFIG_KALLSYMS section)
+#
+# vmlinux version cannot be updated during normal descending-into-subdirs
+# phase since we do not yet know if we need to update vmlinux.
+# Therefore this step is delayed until just before final link of vmlinux -
+# except in kallsyms case where it is done just before adding the
+# symbols to the kernel.
+#
+# System.map is generated to document addresses of all kernel symbols
 
-#	This is a bit tricky: If we need to relink vmlinux, we want
-#	the version number incremented, which means recompile init/version.o
-#	and relink init/init.o. However, we cannot do this during the
-#       normal descending-into-subdirs phase, since at that time
-#       we cannot yet know if we will need to relink vmlinux.
-#	So we descend into init/ inside the rule for vmlinux again.
-vmlinux-objs := $(head-y) $(init-y) $(core-y) $(libs-y) $(drivers-y) $(net-y)
-
-quiet_cmd_vmlinux__ = LD      $@
-define cmd_vmlinux__
-	$(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) $(head-y) $(init-y) \
-	--start-group \
-	$(core-y) \
-	$(libs-y) \
-	$(drivers-y) \
-	$(net-y) \
-	--end-group \
-	$(filter .tmp_kallsyms%,$^) \
-	-o $@
-endef
+vmlinux-init := $(head-y) $(init-y)
+vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
+vmlinux-all  := $(vmlinux-init) built-in.o
+vmlinux-lds  := arch/$(ARCH)/kernel/vmlinux.lds
+
+# Rule to link vmlinux - also used during CONFIG_KALLSYMS
+# May be overridden by arch/$(ARCH)/Makefile
+quiet_cmd_vmlinux__  = LD      $@
+      cmd_vmlinux__  = $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) \
+                           -T $(filter-out FORCE, $^) -o $@
+
+# Generate new vmlinux version
+quiet_cmd_vmlinux_version = GEN     .version
+      cmd_vmlinux_version = set -e;                     \
+	. $(srctree)/scripts/mkversion > .tmp_version;	\
+	mv -f .tmp_version .version;			\
+	$(MAKE) $(build)=init
+	
+# Generate System.map
+quiet_cmd_sysmap = SYSMAP 
+      cmd_sysmap = $(CONFIG_SHELL) $(srctree)/scripts/mksysmap
 
-#	set -e makes the rule exit immediately on error
+# Link of vmlinux
+# If CONFIG_KALLSYMS is set .version is already updated
+# Generate System.map and verify that the content is consistent
 
 define rule_vmlinux__
-	+set -e;							\
-	$(if $(filter .tmp_kallsyms%,$^),,				\
-	  echo '  GEN     .version';					\
-	  . $(srctree)/scripts/mkversion > .tmp_version;		\
-	  mv -f .tmp_version .version;					\
-	  $(MAKE) $(build)=init;					\
-	)								\
-	$(if $($(quiet)cmd_vmlinux__),					\
-	  echo '  $($(quiet)cmd_vmlinux__)' &&) 			\
-	$(cmd_vmlinux__);						\
-	echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
+	$(if $(CONFIG_KALLSYMS),,$(call cmd,vmlinux_version))
+	
+	$(call cmd,vmlinux__)
+	$(Q)echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
+	
+	$(Q)$(if $($(quiet)cmd_sysmap),                 \
+	  echo '  $($(quiet)cmd_sysmap) System.map' &&) \
+	$(cmd_sysmap) $@ System.map;                    \
+	if [ $$? -ne 0 ]; then                          \
+		rm -f $@;                               \
+		/bin/false;                             \
+	fi;
+	$(verify_kallsyms)
 endef
 
-quiet_cmd_sysmap = SYSMAP 
-      cmd_sysmap = $(CONFIG_SHELL) $(srctree)/scripts/mksysmap
-		   
-LDFLAGS_vmlinux += -T arch/$(ARCH)/kernel/vmlinux.lds
-
-#	Generate section listing all symbols and add it into vmlinux
-#	It's a three stage process:
-#	o .tmp_vmlinux1 has all symbols and sections, but __kallsyms is
-#	  empty
-#	  Running kallsyms on that gives us .tmp_kallsyms1.o with
-#	  the right size
-#	o .tmp_vmlinux2 now has a __kallsyms section of the right size,
-#	  but due to the added section, some addresses have shifted
-#	  From here, we generate a correct .tmp_kallsyms2.o
-#	o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
-#	o Verify that the System.map from vmlinux matches the map from
-#	  .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
-#	o If CONFIG_KALLSYMS_EXTRA_PASS is set, do an extra pass using
-#	  .tmp_vmlinux3 and .tmp_kallsyms3.o.  This is only meant as a
-#	  temporary bypass to allow the kernel to be built while the
-#	  maintainers work out what went wrong with kallsyms.
 
 ifdef CONFIG_KALLSYMS
+# Generate section listing all symbols and add it into vmlinux $(kallsyms.o)
+# It's a three stage process:
+# o .tmp_vmlinux1 has all symbols and sections, but __kallsyms is
+#   empty
+#   Running kallsyms on that gives us .tmp_kallsyms1.o with
+#   the right size - vmlinux version updated during this step
+# o .tmp_vmlinux2 now has a __kallsyms section of the right size,
+#   but due to the added section, some addresses have shifted.
+#   From here, we generate a correct .tmp_kallsyms2.o
+# o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
+# o Verify that the System.map from vmlinux matches the map from
+#   .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
+# o If CONFIG_KALLSYMS_EXTRA_PASS is set, do an extra pass using
+#   .tmp_vmlinux3 and .tmp_kallsyms3.o.  This is only meant as a
+#   temporary bypass to allow the kernel to be built while the
+#   maintainers work out what went wrong with kallsyms.
 
 ifdef CONFIG_KALLSYMS_EXTRA_PASS
 last_kallsyms := 3
@@ -615,16 +639,28 @@
 
 kallsyms.o := .tmp_kallsyms$(last_kallsyms).o
 
-define rule_verify_kallsyms
+define verify_kallsyms
 	$(Q)$(if $($(quiet)cmd_sysmap),                       \
 	  echo '  $($(quiet)cmd_sysmap) .tmp_System.map' &&)  \
 	  $(cmd_sysmap) .tmp_vmlinux$(last_kallsyms) .tmp_System.map
-	$(Q)cmp -s System.map .tmp_System.map || \
-		(echo Inconsistent kallsyms data, try setting CONFIG_KALLSYMS_EXTRA_PASS ; rm .tmp_kallsyms* ; false)
+	$(Q)cmp -s System.map .tmp_System.map ||              \
+		(echo Inconsistent kallsyms data;             \
+		 echo Try setting CONFIG_KALLSYMS_EXTRA_PASS; \
+		 rm .tmp_kallsyms* ; /bin/false )
+endef
+
+# Update vmlinux version before link
+cmd_ksym_ld = $(cmd_vmlinux__)
+define rule_ksym_ld
+	$(call cmd,vmlinux_version)
+	$(call cmd,vmlinux__)
+	$(Q)echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
 endef
 
+# Generate .S file with all kernel symbols
 quiet_cmd_kallsyms = KSYM    $@
-cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) $(foreach x,$(CONFIG_KALLSYMS_ALL),--all-symbols) > $@
+      cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \
+                     $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@
 
 .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE
 	$(call if_changed_dep,as_o_S)
@@ -632,43 +668,39 @@
 .tmp_kallsyms%.S: .tmp_vmlinux% $(KALLSYMS)
 	$(call cmd,kallsyms)
 
-.tmp_vmlinux1: $(vmlinux-objs) arch/$(ARCH)/kernel/vmlinux.lds FORCE
-	$(call if_changed_rule,vmlinux__)
+# .tmp_vmlinux1 must be complete except kallsyms, so update vmlinux version
+.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-all) FORCE
+	$(call if_changed_rule,ksym_ld)
 
-.tmp_vmlinux2: $(vmlinux-objs) .tmp_kallsyms1.o arch/$(ARCH)/kernel/vmlinux.lds FORCE
-	$(call if_changed_rule,vmlinux__)
+.tmp_vmlinux2: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms1.o FORCE
+	$(call if_changed,vmlinux__)
 
-.tmp_vmlinux3: $(vmlinux-objs) .tmp_kallsyms2.o arch/$(ARCH)/kernel/vmlinux.lds FORCE
-	$(call if_changed_rule,vmlinux__)
+.tmp_vmlinux3: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms2.o FORCE
+	$(call if_changed,vmlinux__)
 
 # Needs to visit scripts/ before $(KALLSYMS) can be used.
 $(KALLSYMS): scripts ;
 
-endif
-
-# Finally the vmlinux rule
-# This rule is also used to generate System.map
-# and to verify that the content of kallsyms are consistent
-
-define rule_vmlinux
-	$(rule_vmlinux__);
-	$(Q)$(if $($(quiet)cmd_sysmap),                  \
-	  echo '  $($(quiet)cmd_sysmap) System.map' &&)  \
-	$(cmd_sysmap) $@ System.map;                     \
-	if [ $$? -ne 0 ]; then                           \
-		rm -f $@;                                \
-		/bin/false;                              \
-	fi;
-	$(rule_verify_kallsyms)
-endef
+endif # ifdef CONFIG_KALLSYMS
 
-vmlinux: $(vmlinux-objs) $(kallsyms.o) arch/$(ARCH)/kernel/vmlinux.lds FORCE
-	$(call if_changed_rule,vmlinux)
-
-#	The actual objects are generated when descending, 
-#	make sure no implicit rule kicks in
+# vmlinux image - including updated kernel symbols
+vmlinux: $(vmlinux-lds) $(vmlinux-init) built-in.o $(kallsyms.o) FORCE
+	$(call if_changed_rule,vmlinux__)
 
-$(sort $(vmlinux-objs)) arch/$(ARCH)/kernel/vmlinux.lds: $(vmlinux-dirs) ;
+# Link $(vmlinux-main) to speed up rest of build phase. No need to
+# relink this part too many times.
+# Use start/end-group to make sure to resolve all possible symbols
+quiet_rule_vmlinux_partial = LD      $@
+       cmd_vmlinux_partial = $(LD) $(LDFLAGS) $(LDFLAGS_$(*F)) -r \
+                                   --start-group $(filter-out FORCE, $^) \
+				   --end-group -o $@
+				   
+built-in.o: $(vmlinux-main) FORCE
+	$(call if_changed,vmlinux_partial)
+
+# The actual objects are generated when descending, 
+# make sure no implicit rule kicks in
+$(sort $(vmlinux-init) $(vmlinux-main)) $(vmlinux-lds): $(vmlinux-dirs) ;
 
 # Handle descending into subdirectories listed in $(vmlinux-dirs)
 # Preset locale variables to speed up the build process. Limit locale
@@ -1188,13 +1220,22 @@
   include $(cmd_files)
 endif
 
+# Execute command and generate cmd file
+if_changed = $(if $(strip $? \
+		          $(filter-out $(cmd_$(1)),$(cmd_$@))\
+			  $(filter-out $(cmd_$@),$(cmd_$(1)))),\
+	@set -e; \
+	$(if $($(quiet)cmd_$(1)),echo '  $(subst ','\'',$($(quiet)cmd_$(1)))';) \
+	$(cmd_$(1)); \
+	echo 'cmd_$@ := $(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).cmd)
+
+
 # execute the command and also postprocess generated .d dependencies
 # file
-
 if_changed_dep = $(if $(strip $? $(filter-out FORCE $(wildcard $^),$^)\
 		          $(filter-out $(cmd_$(1)),$(cmd_$@))\
 			  $(filter-out $(cmd_$@),$(cmd_$(1)))),\
-	@set -e; \
+	$(Q)set -e; \
 	$(if $($(quiet)cmd_$(1)),echo '  $(subst ','\'',$($(quiet)cmd_$(1)))';) \
 	$(cmd_$(1)); \
 	scripts/basic/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
@@ -1208,7 +1249,7 @@
 if_changed_rule = $(if $(strip $? \
 		               $(filter-out $(cmd_$(1)),$(cmd_$(@F)))\
 			       $(filter-out $(cmd_$(@F)),$(cmd_$(1)))),\
-	               @$(rule_$(1)))
+	               $(Q)$(rule_$(1)))
 
 # If quiet is set, only print short version of command
 

Re: kbuild: Simplify vmlinux generation

[Sam Ravnborg]

Not posted to lkml:
o Update ver_linux to include current reiserfsprogs (Steven Cole)

--- bk-current/scripts/ver_linux.orig	2004-08-31 22:00:44.506377680 -0600
+++ bk-current/scripts/ver_linux	2004-08-31 22:04:59.844560376 -0600
@@ -37,8 +37,11 @@
 fsck.jfs -V 2>&1 | grep version | sed 's/,//' |  awk \
 'NR==1 {print "jfsutils              ", $3}'
 
-reiserfsck -V 2>&1 | grep reiserfsprogs | awk \
-'NR==1{print "reiserfsprogs         ", $NF}'
+reiserfsck -V 2>&1 | grep reiserfsck | awk \
+'NR==1{print "reiserfsprogs         ", $2}'
+
+fsck.reiser4 -V 2>&1 | grep fsck.reiser4 | awk \
+'NR==1{print "reiser4progs          ", $2}'
 
 xfs_db -V 2>&1 | grep version | awk \
 'NR==1{print "xfsprogs              ", $3}'

Re: kbuild: Simplify vmlinux generation

[Horst von Brand]

Sam Ravnborg <sam@ravnborg.org> said:

[...]

Some comments interspersed.

Signed off by: Horst H. von Brand <vonbrand@inf.utfsm.cl>

(Not too much intellect in here, and no property, but...)

> diff -Nru a/Makefile b/Makefile
> --- a/Makefile	2004-09-05 22:06:47 +02:00
> +++ b/Makefile	2004-09-05 22:06:47 +02:00
> @@ -545,67 +545,91 @@
>  
>  # Build vmlinux
>  # ---------------------------------------------------------------------------
> +# vmlinux is build from the objects seleted by $(vmlinux-init) and

                                       selected

> +# $(vmlinux-main). Most are built-in.o files from top-level directories
> +# in the kernel tree, others are specified in arch/$(ARCH)Makefile.
> +# Ordering when linking is important, and $(vmlinux-init) must be first.
> +#
> +# vmlinux
> +#   ^
> +#   |
> +#   +-< $(vmlinux-init)
> +#   |   +--< init/version.o + more
> +#   |
> +#   +-< built-in.o
> +#   |   +--< $(vmlinux-main)
> +#   |        +--< driver/built-in.o mm/built-in.o + more
> +#   |
> +#   +-< kallsyms.o (see description in CONFIG_KALLSYMS section)
> +#
> +# vmlinux version cannot be updated during normal descending-into-subdirs

     The vmlinux version? Or some file?

> +# phase since we do not yet know if we need to update vmlinux.
> +# Therefore this step is delayed until just before final link of vmlinux -
> +# except in kallsyms case where it is done just before adding the

            in the kallsyms case

> +# symbols to the kernel.
> +#
> +# System.map is generated to document addresses of all kernel symbols
>  
> -#	This is a bit tricky: If we need to relink vmlinux, we want
> -#	the version number incremented, which means recompile init/version.o
> -#	and relink init/init.o. However, we cannot do this during the
> -#       normal descending-into-subdirs phase, since at that time
> -#       we cannot yet know if we will need to relink vmlinux.
> -#	So we descend into init/ inside the rule for vmlinux again.
> -vmlinux-objs := $(head-y) $(init-y) $(core-y) $(libs-y) $(drivers-y) $(net-y)
> -
> -quiet_cmd_vmlinux__ = LD      $@
> -define cmd_vmlinux__
> -	$(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) $(head-y) $(init-y) \
> -	--start-group \
> -	$(core-y) \
> -	$(libs-y) \
> -	$(drivers-y) \
> -	$(net-y) \
> -	--end-group \
> -	$(filter .tmp_kallsyms%,$^) \
> -	-o $@
> -endef
> +vmlinux-init := $(head-y) $(init-y)
> +vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
> +vmlinux-all  := $(vmlinux-init) built-in.o
> +vmlinux-lds  := arch/$(ARCH)/kernel/vmlinux.lds
> +
> +# Rule to link vmlinux - also used during CONFIG_KALLSYMS
> +# May be overridden by arch/$(ARCH)/Makefile
> +quiet_cmd_vmlinux__  = LD      $@
> +      cmd_vmlinux__  = $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) \
> +                           -T $(filter-out FORCE, $^) -o $@
> +
> +# Generate new vmlinux version
> +quiet_cmd_vmlinux_version = GEN     .version
> +      cmd_vmlinux_version = set -e;                     \
> +	. $(srctree)/scripts/mkversion > .tmp_version;	\
> +	mv -f .tmp_version .version;			\
> +	$(MAKE) $(build)=init
> +	
> +# Generate System.map
> +quiet_cmd_sysmap = SYSMAP 
> +      cmd_sysmap = $(CONFIG_SHELL) $(srctree)/scripts/mksysmap
>  
> -#	set -e makes the rule exit immediately on error
> +# Link of vmlinux
> +# If CONFIG_KALLSYMS is set .version is already updated
> +# Generate System.map and verify that the content is consistent
>  
>  define rule_vmlinux__
> -	+set -e;							\
> -	$(if $(filter .tmp_kallsyms%,$^),,				\
> -	  echo '  GEN     .version';					\
> -	  . $(srctree)/scripts/mkversion > .tmp_version;		\
> -	  mv -f .tmp_version .version;					\
> -	  $(MAKE) $(build)=init;					\
> -	)								\
> -	$(if $($(quiet)cmd_vmlinux__),					\
> -	  echo '  $($(quiet)cmd_vmlinux__)' &&) 			\
> -	$(cmd_vmlinux__);						\
> -	echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
> +	$(if $(CONFIG_KALLSYMS),,$(call cmd,vmlinux_version))
> +	
> +	$(call cmd,vmlinux__)
> +	$(Q)echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
> +	
> +	$(Q)$(if $($(quiet)cmd_sysmap),                 \
> +	  echo '  $($(quiet)cmd_sysmap) System.map' &&) \
> +	$(cmd_sysmap) $@ System.map;                    \
> +	if [ $$? -ne 0 ]; then                          \
> +		rm -f $@;                               \
> +		/bin/false;                             \
> +	fi;
> +	$(verify_kallsyms)
>  endef
>  
> -quiet_cmd_sysmap = SYSMAP 
> -      cmd_sysmap = $(CONFIG_SHELL) $(srctree)/scripts/mksysmap
> -		   
> -LDFLAGS_vmlinux += -T arch/$(ARCH)/kernel/vmlinux.lds
> -
> -#	Generate section listing all symbols and add it into vmlinux
> -#	It's a three stage process:
> -#	o .tmp_vmlinux1 has all symbols and sections, but __kallsyms is
> -#	  empty
> -#	  Running kallsyms on that gives us .tmp_kallsyms1.o with
> -#	  the right size
> -#	o .tmp_vmlinux2 now has a __kallsyms section of the right size,
> -#	  but due to the added section, some addresses have shifted
> -#	  From here, we generate a correct .tmp_kallsyms2.o
> -#	o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
> -#	o Verify that the System.map from vmlinux matches the map from
> -#	  .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
> -#	o If CONFIG_KALLSYMS_EXTRA_PASS is set, do an extra pass using
> -#	  .tmp_vmlinux3 and .tmp_kallsyms3.o.  This is only meant as a
> -#	  temporary bypass to allow the kernel to be built while the
> -#	  maintainers work out what went wrong with kallsyms.
>  
>  ifdef CONFIG_KALLSYMS
> +# Generate section listing all symbols and add it into vmlinux $(kallsyms.o)
> +# It's a three stage process:
> +# o .tmp_vmlinux1 has all symbols and sections, but __kallsyms is
> +#   empty
> +#   Running kallsyms on that gives us .tmp_kallsyms1.o with
> +#   the right size - vmlinux version updated during this step

                                        is updated

> +# o .tmp_vmlinux2 now has a __kallsyms section of the right size,
> +#   but due to the added section, some addresses have shifted.
> +#   From here, we generate a correct .tmp_kallsyms2.o
> +# o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
> +# o Verify that the System.map from vmlinux matches the map from
> +#   .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
> +# o If CONFIG_KALLSYMS_EXTRA_PASS is set, do an extra pass using
> +#   .tmp_vmlinux3 and .tmp_kallsyms3.o.  This is only meant as a
> +#   temporary bypass to allow the kernel to be built while the
> +#   maintainers work out what went wrong with kallsyms.
>  
>  ifdef CONFIG_KALLSYMS_EXTRA_PASS
>  last_kallsyms := 3
> @@ -615,16 +639,28 @@
>  
>  kallsyms.o := .tmp_kallsyms$(last_kallsyms).o
>  
> -define rule_verify_kallsyms
> +define verify_kallsyms

Why delete "rule_" here? Down you create a new rule with "rule_"

[No further comments, rest snipped]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: kbuild: Simplify vmlinux generation

[Sam Ravnborg]

On Mon, Sep 06, 2004 at 02:41:39PM -0400, Horst von Brand wrote:
> Sam Ravnborg <sam@ravnborg.org> said:
> 
> [...]
> 
> Some comments interspersed.
> 
> Signed off by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> 
> (Not too much intellect in here, and no property, but...)

If you could just tell me why akpm's x86_64 do not boot with this one :-(
I will fix my wording as you suggest - thanks.

 > +#
> > +# vmlinux version cannot be updated during normal descending-into-subdirs
> 
>      The vmlinux version? Or some file?
uname -v (the number after #)

> >  
> > -define rule_verify_kallsyms
> > +define verify_kallsyms
> 
> Why delete "rule_" here? Down you create a new rule with "rule_"

rule_ is used only for the defines used in $(call if_changed_rule ...
verify_kallsyms are called direct.

rule_ksym_ld is called using $(if_changed_rule ...)

	Sam

Re: kbuild: Simplify vmlinux generation

[Sam Ravnborg]

On Mon, Sep 06, 2004 at 02:41:39PM -0400, Horst von Brand wrote:
> Sam Ravnborg <sam@ravnborg.org> said:
> 
> [...]
> 
> Some comments interspersed.


To address the lock-up issue Andrew hit I dropped the built-in.o intermidiate
step.
Will be pushed out if I receive a success report.

	Sam
	
Following patch apply on top of the last posted:

===== Makefile 1.531 vs edited =====
--- 1.531/Makefile	2004-09-06 20:22:01 +02:00
+++ edited/Makefile	2004-09-06 21:04:01 +02:00
@@ -545,7 +545,7 @@
 
 # Build vmlinux
 # ---------------------------------------------------------------------------
-# vmlinux is build from the objects seleted by $(vmlinux-init) and
+# vmlinux is build from the objects selected by $(vmlinux-init) and
 # $(vmlinux-main). Most are built-in.o files from top-level directories
 # in the kernel tree, others are specified in arch/$(ARCH)Makefile.
 # Ordering when linking is important, and $(vmlinux-init) must be first.
@@ -556,30 +556,33 @@
 #   +-< $(vmlinux-init)
 #   |   +--< init/version.o + more
 #   |
-#   +-< built-in.o
-#   |   +--< $(vmlinux-main)
-#   |        +--< driver/built-in.o mm/built-in.o + more
+#   +--< $(vmlinux-main)
+#   |    +--< driver/built-in.o mm/built-in.o + more
 #   |
 #   +-< kallsyms.o (see description in CONFIG_KALLSYMS section)
 #
-# vmlinux version cannot be updated during normal descending-into-subdirs
-# phase since we do not yet know if we need to update vmlinux.
+# vmlinux version (uname -v) cannot be updated during normal
+# descending-into-subdirs phase since we do not yet know if we need to
+# update vmlinux.
 # Therefore this step is delayed until just before final link of vmlinux -
-# except in kallsyms case where it is done just before adding the
+# except in the kallsyms case where it is done just before adding the
 # symbols to the kernel.
 #
 # System.map is generated to document addresses of all kernel symbols
 
 vmlinux-init := $(head-y) $(init-y)
 vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
-vmlinux-all  := $(vmlinux-init) built-in.o
+vmlinux-all  := $(vmlinux-init) $(vmlinux-main)
 vmlinux-lds  := arch/$(ARCH)/kernel/vmlinux.lds
 
 # Rule to link vmlinux - also used during CONFIG_KALLSYMS
 # May be overridden by arch/$(ARCH)/Makefile
+# Require first prerequisite to be the lds file
 quiet_cmd_vmlinux__  = LD      $@
-      cmd_vmlinux__  = $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) \
-                           -T $(filter-out FORCE, $^) -o $@
+      cmd_vmlinux__  = $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+      -T $(vmlinux-lds) $(vmlinux-init)                          \
+      --start-group $(vmlinux-main) --end-group                  \
+      $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^)
 
 # Generate new vmlinux version
 quiet_cmd_vmlinux_version = GEN     .version
@@ -619,7 +622,7 @@
 # o .tmp_vmlinux1 has all symbols and sections, but __kallsyms is
 #   empty
 #   Running kallsyms on that gives us .tmp_kallsyms1.o with
-#   the right size - vmlinux version updated during this step
+#   the right size - vmlinux version (uname -v) is updated during this step
 # o .tmp_vmlinux2 now has a __kallsyms section of the right size,
 #   but due to the added section, some addresses have shifted.
 #   From here, we generate a correct .tmp_kallsyms2.o
@@ -684,19 +687,8 @@
 endif # ifdef CONFIG_KALLSYMS
 
 # vmlinux image - including updated kernel symbols
-vmlinux: $(vmlinux-lds) $(vmlinux-init) built-in.o $(kallsyms.o) FORCE
+vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
 	$(call if_changed_rule,vmlinux__)
-
-# Link $(vmlinux-main) to speed up rest of build phase. No need to
-# relink this part too many times.
-# Use start/end-group to make sure to resolve all possible symbols
-quiet_rule_vmlinux_partial = LD      $@
-       cmd_vmlinux_partial = $(LD) $(LDFLAGS) $(LDFLAGS_$(*F)) -r \
-                                   --start-group $(filter-out FORCE, $^) \
-				   --end-group -o $@
-				   
-built-in.o: $(vmlinux-main) FORCE
-	$(call if_changed,vmlinux_partial)
 
 # The actual objects are generated when descending, 
 # make sure no implicit rule kicks in

[PATCH v2] x86,vdso: Fix vdso_install

[Andy Lutomirski]

The filenames are different now.  Inspired by a patch from
Sam Ravnborg.

Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/vdso/Makefile | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 9769df0..e3683d6 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI)	:= y
 VDSO32-$(CONFIG_X86_32)		:= y
 VDSO32-$(CONFIG_COMPAT)		:= y
 
-vdso-install-$(VDSO64-y)	+= vdso.so
-vdso-install-$(VDSOX32-y)	+= vdsox32.so
-vdso-install-$(VDSO32-y)	+= $(vdso32-images)
-
-
 # files to link into the vdso
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
 
@@ -176,15 +171,20 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
 GCOV_PROFILE := n
 
 #
-# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
+# Install the unstripped copies of vdso*.so.
 #
-quiet_cmd_vdso_install = INSTALL $@
-      cmd_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/vdso/$@
-$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
+quiet_cmd_vdso_install = INSTALL $(@:install_%=%)
+      cmd_vdso_install = cp $< $(MODLIB)/vdso/$(@:install_%=%)
+
+vdso_img_insttargets := $(vdso_img_sodbg:%=install_%)
+
+$(MODLIB)/vdso: FORCE
 	@mkdir -p $(MODLIB)/vdso
+
+$(vdso_img_insttargets): install_%: $(obj)/% $(MODLIB)/vdso FORCE
 	$(call cmd,vdso_install)
 
-PHONY += vdso_install $(vdso-install-y)
-vdso_install: $(vdso-install-y)
+PHONY += vdso_install $(vdso_img_insttargets)
+vdso_install: $(vdso_img_insttargets) FORCE
 
 clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*
-- 
1.9.3

Re: [PATCH v2] x86,vdso: Fix vdso_install

[Sam Ravnborg]

On Wed, Jun 11, 2014 at 12:25:29PM -0700, Andy Lutomirski wrote:
> The filenames are different now.  Inspired by a patch from
> Sam Ravnborg.
> 
> Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Better than the first version - thanks!

Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

Re: [PATCH v2] x86,vdso: Fix vdso_install

[Josh Boyer]

On Wed, Jun 11, 2014 at 3:25 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> The filenames are different now.  Inspired by a patch from
> Sam Ravnborg.
>
> Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  arch/x86/vdso/Makefile | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
> index 9769df0..e3683d6 100644
> --- a/arch/x86/vdso/Makefile
> +++ b/arch/x86/vdso/Makefile
> @@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI)  := y
>  VDSO32-$(CONFIG_X86_32)                := y
>  VDSO32-$(CONFIG_COMPAT)                := y
>
> -vdso-install-$(VDSO64-y)       += vdso.so
> -vdso-install-$(VDSOX32-y)      += vdsox32.so
> -vdso-install-$(VDSO32-y)       += $(vdso32-images)
> -
> -
>  # files to link into the vdso
>  vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
>
> @@ -176,15 +171,20 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
>  GCOV_PROFILE := n
>
>  #
> -# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
> +# Install the unstripped copies of vdso*.so.
>  #
> -quiet_cmd_vdso_install = INSTALL $@
> -      cmd_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/vdso/$@
> -$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
> +quiet_cmd_vdso_install = INSTALL $(@:install_%=%)
> +      cmd_vdso_install = cp $< $(MODLIB)/vdso/$(@:install_%=%)
> +
> +vdso_img_insttargets := $(vdso_img_sodbg:%=install_%)
> +
> +$(MODLIB)/vdso: FORCE
>         @mkdir -p $(MODLIB)/vdso
> +
> +$(vdso_img_insttargets): install_%: $(obj)/% $(MODLIB)/vdso FORCE
>         $(call cmd,vdso_install)
>
> -PHONY += vdso_install $(vdso-install-y)
> -vdso_install: $(vdso-install-y)
> +PHONY += vdso_install $(vdso_img_insttargets)
> +vdso_install: $(vdso_img_insttargets) FORCE

OK, so I can't tell from the changelog if this is intentional or not,
but now this installs e.g. vdso64.so.dbg instead of vdso64.so.

[jwboyer@sb vdso]$ pwd
/lib/modules/3.16.0-0.rc0.git3.1.fc21.x86_64/vdso
[jwboyer@sb vdso]$ ls
vdso32-int80.so.dbg  vdso32-syscall.so.dbg  vdso32-sysenter.so.dbg
vdso64.so.dbg
[jwboyer@sb vdso]$

If it's intentional, you might want to make the changelog a bit more verbose.

josh

[PATCH v3] x86,vdso: Fix vdso_install

[Andy Lutomirski]

The filenames are different now.  Inspired by a patch from
Sam Ravnborg.

Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---

I kept Sam's ack from v2, since v3 has only a trivial change.

Changes from v1: Remove core kbuild change
Changes from v2: Name the result .so files again, not .so.dbg

 arch/x86/vdso/Makefile | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 9769df0..845b45e 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI)	:= y
 VDSO32-$(CONFIG_X86_32)		:= y
 VDSO32-$(CONFIG_COMPAT)		:= y
 
-vdso-install-$(VDSO64-y)	+= vdso.so
-vdso-install-$(VDSOX32-y)	+= vdsox32.so
-vdso-install-$(VDSO32-y)	+= $(vdso32-images)
-
-
 # files to link into the vdso
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
 
@@ -176,15 +171,20 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
 GCOV_PROFILE := n
 
 #
-# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
+# Install the unstripped copies of vdso*.so.
 #
-quiet_cmd_vdso_install = INSTALL $@
-      cmd_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/vdso/$@
-$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
+quiet_cmd_vdso_install = INSTALL $(@:install_%=%)
+      cmd_vdso_install = cp $< $(MODLIB)/vdso/$(@:install_%=%)
+
+vdso_img_insttargets := $(vdso_img_sodbg:%.dbg=install_%)
+
+$(MODLIB)/vdso: FORCE
 	@mkdir -p $(MODLIB)/vdso
+
+$(vdso_img_insttargets): install_%: $(obj)/%.dbg $(MODLIB)/vdso FORCE
 	$(call cmd,vdso_install)
 
-PHONY += vdso_install $(vdso-install-y)
-vdso_install: $(vdso-install-y)
+PHONY += vdso_install $(vdso_img_insttargets)
+vdso_install: $(vdso_img_insttargets) FORCE
 
 clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*
-- 
1.9.3

Re: [PATCH v3] x86,vdso: Fix vdso_install

[Josh Boyer]

On Thu, Jun 12, 2014 at 11:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> The filenames are different now.  Inspired by a patch from
> Sam Ravnborg.
>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Things look great with this version.  Thanks much!

Tested-by: Josh Boyer <jwboyer@fedoraproject.org>

> ---
>
> I kept Sam's ack from v2, since v3 has only a trivial change.
>
> Changes from v1: Remove core kbuild change
> Changes from v2: Name the result .so files again, not .so.dbg
>
>  arch/x86/vdso/Makefile | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
> index 9769df0..845b45e 100644
> --- a/arch/x86/vdso/Makefile
> +++ b/arch/x86/vdso/Makefile
> @@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI)  := y
>  VDSO32-$(CONFIG_X86_32)                := y
>  VDSO32-$(CONFIG_COMPAT)                := y
>
> -vdso-install-$(VDSO64-y)       += vdso.so
> -vdso-install-$(VDSOX32-y)      += vdsox32.so
> -vdso-install-$(VDSO32-y)       += $(vdso32-images)
> -
> -
>  # files to link into the vdso
>  vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
>
> @@ -176,15 +171,20 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
>  GCOV_PROFILE := n
>
>  #
> -# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
> +# Install the unstripped copies of vdso*.so.
>  #
> -quiet_cmd_vdso_install = INSTALL $@
> -      cmd_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/vdso/$@
> -$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
> +quiet_cmd_vdso_install = INSTALL $(@:install_%=%)
> +      cmd_vdso_install = cp $< $(MODLIB)/vdso/$(@:install_%=%)
> +
> +vdso_img_insttargets := $(vdso_img_sodbg:%.dbg=install_%)
> +
> +$(MODLIB)/vdso: FORCE
>         @mkdir -p $(MODLIB)/vdso
> +
> +$(vdso_img_insttargets): install_%: $(obj)/%.dbg $(MODLIB)/vdso FORCE
>         $(call cmd,vdso_install)
>
> -PHONY += vdso_install $(vdso-install-y)
> -vdso_install: $(vdso-install-y)
> +PHONY += vdso_install $(vdso_img_insttargets)
> +vdso_install: $(vdso_img_insttargets) FORCE
>
>  clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*
> --
> 1.9.3
>

Re: [PATCH v3] x86,vdso: Fix vdso_install

[H. Peter Anvin]

On 06/12/2014 10:01 AM, Josh Boyer wrote:
> On Thu, Jun 12, 2014 at 11:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> The filenames are different now.  Inspired by a patch from
>> Sam Ravnborg.
>>
>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>> Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> 
> Things look great with this version.  Thanks much!
> 
> Tested-by: Josh Boyer <jwboyer@fedoraproject.org>
> 

Are we okay with the 64-bit vdso now being installed as vdso64.so?

	-hpa

Re: [PATCH v3] x86,vdso: Fix vdso_install

[Andy Lutomirski]

On Fri, Jun 13, 2014 at 10:24 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 06/12/2014 10:01 AM, Josh Boyer wrote:
>> On Thu, Jun 12, 2014 at 11:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> The filenames are different now.  Inspired by a patch from
>>> Sam Ravnborg.
>>>
>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>>> Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>
>> Things look great with this version.  Thanks much!
>>
>> Tested-by: Josh Boyer <jwboyer@fedoraproject.org>
>>
>
> Are we okay with the 64-bit vdso now being installed as vdso64.so?

Unless someone actually complains, I think so.  Ideally, I think we'd
have a symlink from the build id, but that's a separate issue.

AFAIK, the only thing that actually references these files is Fedora's
gdb, which is finding them from Fedora's build-id symlinks, which
should work fine regardless of what the thing is called.

How's this for a patch description:

make vdso_install has been broken since this commit:

commit 6f121e548f83674ab4920a4e60afb58d4f61b829
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Mon May 5 12:19:34 2014 -0700

    x86, vdso: Reimplement vdso.so preparation in build-time C

because the names of the files to be installed changed.   This fixes
vdso_install to install the right files.

[tip:x86/vdso] x86/vdso: Fix vdso_install

[tip-bot for Andy Lutomirski]

Commit-ID:  a934fb5bc9cd1260be89272cfb7a6c9dc71974d7
Gitweb:     http://git.kernel.org/tip/a934fb5bc9cd1260be89272cfb7a6c9dc71974d7
Author:     Andy Lutomirski <luto@amacapital.net>
AuthorDate: Thu, 12 Jun 2014 08:28:10 -0700
Committer:  H. Peter Anvin <hpa@zytor.com>
CommitDate: Fri, 13 Jun 2014 10:31:48 -0700

x86/vdso: Fix vdso_install

"make vdso_install" installs unstripped versions of the vdso objects
for the benefit of the debugger.  This was broken by checkin:

6f121e548f83 x86, vdso: Reimplement vdso.so preparation in build-time C

The filenames are different now, so update the Makefile to cope.

This still installs the 64-bit vdso as vdso64.so.  We believe this
will be okay, as the only known user is a patched gdb which is known
to use build-ids, but if it turns out to be a problem we may have to
add a link.

Inspired by a patch from Sam Ravnborg.

Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/b10299edd8ba98d17e07dafcd895b8ecf4d99eff.1402586707.git.luto@amacapital.net
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
 arch/x86/vdso/Makefile | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index ba6fc27..3c0809a 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI)	:= y
 VDSO32-$(CONFIG_X86_32)		:= y
 VDSO32-$(CONFIG_COMPAT)		:= y
 
-vdso-install-$(VDSO64-y)	+= vdso.so
-vdso-install-$(VDSOX32-y)	+= vdsox32.so
-vdso-install-$(VDSO32-y)	+= $(vdso32-images)
-
-
 # files to link into the vdso
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vdso-fakesections.o
 vobjs-nox32 := vdso-fakesections.o
@@ -178,15 +173,20 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
 GCOV_PROFILE := n
 
 #
-# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
+# Install the unstripped copies of vdso*.so.
 #
-quiet_cmd_vdso_install = INSTALL $@
-      cmd_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/vdso/$@
-$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
+quiet_cmd_vdso_install = INSTALL $(@:install_%=%)
+      cmd_vdso_install = cp $< $(MODLIB)/vdso/$(@:install_%=%)
+
+vdso_img_insttargets := $(vdso_img_sodbg:%.dbg=install_%)
+
+$(MODLIB)/vdso: FORCE
 	@mkdir -p $(MODLIB)/vdso
+
+$(vdso_img_insttargets): install_%: $(obj)/%.dbg $(MODLIB)/vdso FORCE
 	$(call cmd,vdso_install)
 
-PHONY += vdso_install $(vdso-install-y)
-vdso_install: $(vdso-install-y)
+PHONY += vdso_install $(vdso_img_insttargets)
+vdso_install: $(vdso_img_insttargets) FORCE
 
 clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*