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
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/06/07 22:56:31+02:00 [email protected]
# 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 <[email protected]>
#
# arch/i386/Makefile
# 2004/06/07 22:56:16+02:00 [email protected] +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 [email protected] +36 -0
# Add i386 config options to select kernel image
#
# Makefile
# 2004/06/07 22:56:16+02:00 [email protected] +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
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/06/14 21:22:52+02:00 [email protected]
# 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 <[email protected]>
#
# scripts/package/Makefile
# 2004/06/14 21:22:37+02:00 [email protected] +55 -0
#
# scripts/package/mkspec
# 2004/06/14 21:22:37+02:00 [email protected] +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 [email protected] +0 -0
# BitKeeper file /home/sam/bk/kbuild/scripts/package/Makefile
#
# scripts/Makefile
# 2004/06/14 21:22:37+02:00 [email protected] +1 -1
# Clean in package/ as well
#
# Makefile
# 2004/06/14 21:22:37+02:00 [email protected] +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 [email protected] +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 <[email protected]>
-#
-# 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 <[email protected]>
+#
+
+# 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 ""
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/06/14 21:44:27+02:00 [email protected]
# kbuild: Added deb target
#
# Script originally from Wichert Akkerman <[email protected]>
# Modified to support multiple architectures.
#
# Signed-off-by: Sam Ravnborg <[email protected]>
#
# scripts/package/builddeb
# 2004/06/14 21:44:12+02:00 [email protected] +79 -0
#
# scripts/package/builddeb
# 2004/06/14 21:44:12+02:00 [email protected] +0 -0
# BitKeeper file /home/sam/bk/kbuild/scripts/package/builddeb
#
# scripts/package/Makefile
# 2004/06/14 21:44:12+02:00 [email protected] +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 <[email protected]>
+#
+# 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
+
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/06/14 22:21:46+02:00 [email protected]
# 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 <[email protected]>
#
# Documentation/kbuild/extmodules.txt
# 2004/06/14 22:21:32+02:00 [email protected] +168 -0
#
# Documentation/kbuild/extmodules.txt
# 2004/06/14 22:21:32+02:00 [email protected] +0 -0
# BitKeeper file /home/sam/bk/kbuild/Documentation/kbuild/extmodules.txt
#
# Documentation/kbuild/00-INDEX
# 2004/06/14 22:21:32+02:00 [email protected] +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.
+
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/06/14 22:09:53+02:00 [email protected]
# 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 <[email protected]>
#
# Makefile
# 2004/06/14 22:09:39+02:00 [email protected] +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 <[email protected]>
#
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*
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
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
Previously Sam Ravnborg wrote:
> +# Deb target
> +# ---------------------------------------------------------------------------
> +#
> +.PHONY: rpm-pkg rpm
> +deb-pkg:
Shouldn't that .PHONY reference deb-pkg instead?
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
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
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
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 [email protected]
# kbuild: Added deb target
#
# Script originally from Wichert Akkerman <[email protected]>
# Modified to support multiple architectures.
#
# Signed-off-by: Sam Ravnborg <[email protected]>
#
# scripts/package/builddeb
# 2004/06/14 21:44:12+02:00 [email protected] +79 -0
#
# scripts/package/builddeb
# 2004/06/14 21:44:12+02:00 [email protected] +0 -0
# BitKeeper file /home/sam/bk/kbuild/scripts/package/builddeb
#
# scripts/package/Makefile
# 2004/06/14 21:44:12+02:00 [email protected] +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 <[email protected]>
+#
+# 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
+
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/
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
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 [email protected]
# 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 <[email protected]>
#
# Makefile
# 2004/06/14 22:09:39+02:00 [email protected] +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 <[email protected]>
#
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*
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
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
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 ;-)
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/
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/
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
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
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/
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
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>>
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
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
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/
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
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
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
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
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/
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
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
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
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
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/
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/
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
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/
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
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/
On Wed, 2004-06-16 22:54:16 +0200, Sam Ravnborg <[email protected]>
wrote in message <[email protected]>:
> 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 [email protected] . +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));
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 <[email protected]>
> wrote in message <[email protected]>:
> > 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