Skip to contentSkip to conversation

Pull request for branch linux-cleanup

GIT PULL New Thomas Petazzoni 3 participants 32 messages Jun 13, 2010 – Jun 23, 2010 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hello,

Here is a set of 10 patches that completely rewrites the Linux kernel compilation process in Buildroot. It is supposed to be applied on top of the bootloaders-cleanup branch I've sent yesterday.

I've fairly drastically reduced the number of options to configure the kernel, and particulary removed the horrible mess of version selection. See the first commit in this branch for what remains in terms of configuration options for the kernel. As I've removed quite a few things, I'm interested to know how you're using Buildroot to build your kernel, and whether this proposal still matches your use cases.

Peter: for me, this patch set is ready for inclusion, unless there are comments, of course.

Thomas

The following changes since commit fa2a311b7756fc458ae55b5aa90ac865cef6c498:
Thomas Petazzoni (1):
linux: fix dependency on mkimage

are available in the git repository at:

git://git.busybox.net/~tpetazzoni/git/buildroot linux-cleanup

Thomas Petazzoni (10):
New, simpler, infrastructure for building the Linux kernel Remove old Linux infrastructure
iso9660: take into account the linux changes
module-init-tools: remove support for cross-depmod
module-init-tools: bump version + convert to autotools
linux: Add dependency on host-module-init-tools
Add generic functions to enable/set/disable options in kconfig files
linux: adjust kernel config according to the Buildroot configuration
linux: add support for linux26-{menuconfig,xconfig,gconfig} targets
linux: add support for initramfs

 Config.in                                          |    2 +-
 Makefile                                           |    5 +-
 fs/common.mk                                       |    6 +-
 fs/initramfs/initramfs.mk                          |    2 +
 fs/iso9660/Config.in                               |    4 +-
 fs/iso9660/iso9660.mk                              |    6 +-
 linux/Config.in                                    |  129 +++++
 linux/linux.mk                                     |  169 +++++++
 package/Makefile.package.in                        |   15 +
 ...nit-tools-3.11-add-manpages-config-option.patch |   47 ++
 .../module-init-tools-remove-index.patch           |   12 -
 package/module-init-tools/module-init-tools.mk     |  124 +-----
 package/module-init-tools/module-init-tools.patch  |   77 ---
 target/Makefile.in                                 |   16 -
 target/linux/Config.in                             |   33 --
 target/linux/Config.in.advanced                    |  463 -----------------
 target/linux/Config.in.versions                    |   62 ---
 target/linux/Makefile.in                           |  250 ---------
 target/linux/Makefile.in.advanced                  |  532 --------------------
 19 files changed, 385 insertions(+), 1569 deletions(-)
 create mode 100644 linux/Config.in
 create mode 100644 linux/linux.mk
 create mode 100644 package/module-init-tools/module-init-tools-3.11-add-manpages-config-option.patch
 delete mode 100644 package/module-init-tools/module-init-tools-remove-index.patch
 delete mode 100644 package/module-init-tools/module-init-tools.patch
 delete mode 100644 target/linux/Config.in
 delete mode 100644 target/linux/Config.in.advanced
 delete mode 100644 target/linux/Config.in.versions
 delete mode 100644 target/linux/Makefile.in
 delete mode 100644 target/linux/Makefile.in.advanced

Thanks,

Signature · 1 line
Thomas Petazzoni
#1 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

This patch introduces a single, simple, infrastructure to build the Linux kernel. The configuration is limited to :

* Kernel version: a fixed recent stable version, custom stable version, or custom tarball URL

* Kernel patch: either a local file, directory or an URL

* Kernel configuration: either the name of a defconfig or the location of a custom configuration file

* Kernel image: either uImage, bzImage, zImage or vmlinux.

---
 Config.in       |    2 +-
 Makefile        |    1 +
 linux/Config.in |  129 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 linux/linux.mk  |  120 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 251 insertions(+), 1 deletions(-)
 create mode 100644 linux/Config.in
 create mode 100644 linux/linux.mk
Config.in +1 -1
index f5eb859..0a07576 100644
@@ -295,4 +295,4 @@ source "fs/Config.in"
 
 source "boot/Config.in"
 
-source "target/Config.in"
+source "linux/Config.in"
Makefile +1 -0
index 67e41ae..a72dc80 100644
@@ -322,6 +322,7 @@ endif
 
 include boot/common.mk
 include target/Makefile.in
+include linux/linux.mk
 include fs/common.mk
 
 TARGETS+=erase-fakeroots
linux/Config.in new file +129 -0

129 lines not on this page · raw message

linux/linux.mk new file +120 -0

121 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#2 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi, some comments:

Thomas> This patch introduces a single, simple, infrastructure to build the Thomas> Linux kernel. The configuration is limited to :

Thomas> * Kernel version: a fixed recent stable version, custom stable
Thomas> version, or custom tarball URL

Thomas> * Kernel patch: either a local file, directory or an URL

Thomas> * Kernel configuration: either the name of a defconfig or the
Thomas> location of a custom configuration file

Thomas> * Kernel image: either uImage, bzImage, zImage or vmlinux.

Thomas> +choice
Thomas> + prompt "Kernel version"
Thomas> + default BR2_LINUX_KERNEL_2_6_34
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_2_6_34
Thomas> + bool "2.6.34"
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_STABLE
Thomas> + bool "Custom stable version"

I would drop "stable" here.

Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_TARBALL
Thomas> + bool "Custom tarball"
Thomas> +

What about the same-as-kernel-headers choice? Or perhaps the fixed version should used that?

Thomas> +if BR2_LINUX_KERNEL_CUSTOM_TARBALL Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
Thomas> + string "URL of custom kernel tarball"
Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_CUSTOM_TARBALL

For single options, just adding the 'depends on BR2_LINUX_KERNEL_CUSTOM_TARBALL' is shorter/easier to read than all those endif's - IMHO.

Thomas> +config BR2_LINUX_KERNEL_PATCH
Thomas> + bool "Custom patch for the Linux kernel"
Thomas> +
Thomas> +if BR2_LINUX_KERNEL_PATCH
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_PATCH_LOCATION
Thomas> + string "Location of custom kernel patch"
Thomas> + help

 Thomas> +         The location can be an URL, a file path, or a directory. In
 Thomas> +         the case of a directory, all files matching linux-*.patch
 Thomas> +         will be applied.

Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_PATCH

Why not just keep this a single option and only make it do something if it's different than ""?

Thomas> +choice
Thomas> + prompt "Kernel configuration"
Thomas> + default BR2_LINUX_KERNEL_USE_DEFCONFIG
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_USE_DEFCONFIG
Thomas> + bool "Using a defconfig"
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_USE_CUSTOM
Thomas> + bool "Using a custom config file"
Thomas> +
Thomas> +endchoice
Thomas> +
Thomas> +if BR2_LINUX_KERNEL_USE_DEFCONFIG
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_DEFCONFIG
Thomas> + string "Defconfig name"
Thomas> + help
Thomas> + Name of the defconfig file to use, without the leading
Thomas> + _defconfig.

Trailing.

Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_USE_DEFCONFIG
Thomas> +
Thomas> +if BR2_LINUX_KERNEL_USE_CUSTOM
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_FILE
Thomas> + string "Configuration file path"
Thomas> + help
Thomas> + Path to the kernel configuration file.
Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_USE_CUSTOM

I think it would be nicer to do something like what you're doing with BR2_LINUX_KERNEL_PATCH_LOCATION - E.G. make it autodetect if it's a defconfig in the kernel tree or an external file. You can either do this using $(wildcard ..) (to check if the file exists), or simply check for slashes in the string $(findstring /,..).

If we do this, then I would prefer to give the complete make target for defconfigs - E.G. 'blah_defconfig', no just 'blah'.

Thomas> +choice
Thomas> + prompt "Kernel binary format"
Thomas> + default BR2_LINUX_KERNEL_UIMAGE if !BR2_386
Thomas> + default BR2_LINUX_KERNEL_BZIMAGE if BR2_386

The symbol is BR2_i386. I guess we also want it on BR2_x86_64 as well.

I would have expected to see a hidden BR2_LINUX_KERNEL_FORMAT with the text strings "zImage", "bzImage", "uImage", .. - That can then be used as the make target.

Thomas> +# Get the real Linux version, which tells us where kernel modules are
Thomas> +# going to be installed in the target filesystem.
Thomas> +LINUX26_VERSION_PROBED = $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) --no-print-directory -s kernelrelease

We typically use $(shell ..)

Thomas> +# Download
Thomas> +$(LINUX26_DIR)/.stamp_downloaded:
Thomas> + @$(call MESSAGE,"Downloading kernel")
Thomas> + $(call DOWNLOAD,$(LINUX26_SITE),$(LINUX26_SOURCE))
Thomas> +ifeq ($(BR2_LINUX_KERNEL_PATCH),y) Thomas> +ifneq ($(findstring http://,$(LINUX26_PATCH)),)
Thomas> + $(call DOWNLOAD,$(dir $(LINUX26_PATCH)),$(notdir $(LINUX26_PATCH)))
Thomas> +else ifneq ($(findstring ftp://,$(LINUX26_PATCH)),)
Thomas> + $(call DOWNLOAD,$(dir $(LINUX26_PATCH)),$(notdir $(LINUX26_PATCH)))

You can combine these using $(filter) - E.G.:
ifneq ($(filter http:// ftp://,$(LINUX26_PATCH)),)

Thomas> +# Patch
Thomas> +$(LINUX26_DIR)/.stamp_patched: $(LINUX26_DIR)/.stamp_extracted
Thomas> + @$(call MESSAGE,"Patching kernel")
Thomas> +ifeq ($(BR2_LINUX_KERNEL_PATCH),y)
Thomas> +ifneq ($(findstring http://,$(LINUX26_PATCH)),)
Thomas> + toolchain/patch-kernel.sh $(@D) $(DL_DIR) $(notdir $(LINUX26_PATCH))
Thomas> +else ifneq ($(findstring ftp://,$(LINUX26_PATCH)),)
Thomas> + toolchain/patch-kernel.sh $(@D) $(DL_DIR) $(notdir $(LINUX26_PATCH))

Same as above.

Thomas> +else ifeq ($(shell test -d $(LINUX26_PATCH) && echo "dir"),dir)
Thomas> + toolchain/patch-kernel.sh $(@D) $(LINUX26_PATCH) linux-*.patch

You have to escape the * - E.G. linux-\*.patch

Thomas> +else
Thomas> + toolchain/patch-kernel.sh $(@D) $(dir $(LINUX26_PATCH)) $(notdir $(LINUX26_PATCH))
Thomas> +endif
Thomas> +endif
Thomas> + $(Q)touch $@
Thomas> +
Thomas> +
Thomas> +# Configuration
Thomas> +$(LINUX26_DIR)/.stamp_configured: $(LINUX26_DIR)/.stamp_patched
Thomas> + @$(call MESSAGE,"Configuring kernel")
Thomas> +ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
Thomas> + $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
Thomas> +else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM),y)
Thomas> + cp $(BR2_LINUX_KERNEL_CUSTOM_FILE) $(@D)/.config
Thomas> + yes "" | $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig

Hmm, why the yes '' here and not for defconfig? I would prefer to get rid of it, so the user is in control (they can always use the yes ''|make stuff on the BR commandline if they want unattended builds, like I do for buildbot).

Thomas> +endif
Thomas> + $(Q)touch $@
Thomas> +
Thomas> +# Compilation
Thomas> +$(LINUX26_DIR)/.stamp_compiled: $(LINUX26_DIR)/.stamp_configured
Thomas> + @$(call MESSAGE,"Compiling kernel")
Thomas> + $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D)
Thomas> +ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
Thomas> + $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) uImage

Why not simply $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) $(LINUX26_FORMAT) where LINUX26_FORMAT is uImage/zImage/bzImage? That's afaik how it used to be done.

Thomas> +# Installation
Thomas> +$(LINUX26_DIR)/.stamp_installed: $(LINUX26_DIR)/.stamp_compiled
Thomas> + @$(call MESSAGE,"Installing kernel")
Thomas> + cp $(LINUX26_IMAGE_PATH) $(BINARIES_DIR)
Thomas> + $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) \
Thomas> + INSTALL_MOD_PATH=$(TARGET_DIR) modules_install

Does that do something sane with a nonmodular kernel?

Thomas> + # Remove symbolic links pointing to build directories, not
Thomas> + # relevant on the target
Thomas> + rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_PROBED)/build
Thomas> + rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_PROBED)/source
Thomas> + $(Q)touch $@
Thomas> +
Thomas> +linux26: $(LINUX26_DEPENDENCIES) $(LINUX26_DIR)/.stamp_installed Thomas> +
Thomas> +ifeq ($(BR2_LINUX_KERNEL),y)
Thomas> +TARGETS+=linux26
Thomas> +endif
Thomas> \ No newline at end of file

You're good at this one ;)

Signature · 1 line
Bye, Peter Korsgaard
#3 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Hello Peter,

Thanks for reviewing my changes! My answer to your comments below.

Quoted 11 lines · On Fri, 18 Jun 2010 21:30:06 +0200 Peter Korsgaard <[email protected]> wrote:

Thomas> +choice
Thomas> + prompt "Kernel version"
Thomas> + default BR2_LINUX_KERNEL_2_6_34
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_2_6_34
Thomas> + bool "2.6.34"
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_STABLE
Thomas> + bool "Custom stable version"

I would drop "stable" here.

Why ? Only stable releases, i.e releases available in
http://kernel.org/pub/linux/kernel/v2.6/ are supported. And in this directory, only stable releases are available.

Quoted 7 lines

Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_TARBALL
Thomas> + bool "Custom tarball"
Thomas> +

What about the same-as-kernel-headers choice? Or perhaps the fixed version should used that?

I could add another option to say ? same version as kernel headers ?. However, I'd prefer to keep the "BR2_LINUX_KERNEL_2_6_34" option as it
is: remember that in the external toolchain case, ? same version as kernel headers ? doesn't make sense.

Quoted 11 lines

Thomas> +if BR2_LINUX_KERNEL_CUSTOM_TARBALL Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
Thomas> + string "URL of custom kernel tarball"
Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_CUSTOM_TARBALL

For single options, just adding the 'depends on BR2_LINUX_KERNEL_CUSTOM_TARBALL' is shorter/easier to read than all those endif's - IMHO.

Good idea, will do.

Quoted 8 lines

Thomas> +config BR2_LINUX_KERNEL_PATCH
Thomas> + bool "Custom patch for the Linux kernel"
Thomas> +
Thomas> +if BR2_LINUX_KERNEL_PATCH
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_PATCH_LOCATION
Thomas> + string "Location of custom kernel patch"
Thomas> + help

Quoted 8 lines
 Thomas> +         The location can be an URL, a file path, or a directory. In
 Thomas> +         the case of a directory, all files matching linux-*.patch
 Thomas> +         will be applied.

Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_PATCH

Why not just keep this a single option and only make it do something if it's different than ""?

Good idea, will also do.

Quoted 4 lines

Thomas> + Name of the defconfig file to use, without the leading
Thomas> + _defconfig.

Trailing.

Will fix.

Quoted 11 lines

Thomas> +endif # BR2_LINUX_KERNEL_USE_DEFCONFIG
Thomas> +
Thomas> +if BR2_LINUX_KERNEL_USE_CUSTOM
Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_FILE
Thomas> + string "Configuration file path"
Thomas> + help
Thomas> + Path to the kernel configuration file.
Thomas> +
Thomas> +endif # BR2_LINUX_KERNEL_USE_CUSTOM

Quoted 5 lines

I think it would be nicer to do something like what you're doing with BR2_LINUX_KERNEL_PATCH_LOCATION - E.G. make it autodetect if it's a defconfig in the kernel tree or an external file. You can either do this using $(wildcard ..) (to check if the file exists), or simply check for slashes in the string $(findstring /,..).

Why not, but I would find the semantic of the option rather strange, and there might be corner cases where deciding whether it is a defconfig name or the patch to a configuration file would be difficult. From an user perspective, I think it's clearer to have two separate options for this, rather than a single option with a strange semantic which requires looking at the help text to understand what it actually does.

But of course, if you insist on having this, I'll implement it, no big deal.

Quoted 2 lines

If we do this, then I would prefer to give the complete make target for defconfigs - E.G. 'blah_defconfig', no just 'blah'.

Why not, but this would not be consistent with what we do with U-Boot configuration (in which we also ask only for the board name, and we automatically suffix "_config" to it to configure U-Boot). Of course, if you think the way we do things in U-Boot now is incorrect, we can also fix it, but I'd prefer to have one option or the other, but not an inconsistent mix of both.

Quoted 6 lines

Thomas> +choice
Thomas> + prompt "Kernel binary format"
Thomas> + default BR2_LINUX_KERNEL_UIMAGE if !BR2_386
Thomas> + default BR2_LINUX_KERNEL_BZIMAGE if BR2_386

The symbol is BR2_i386. I guess we also want it on BR2_x86_64 as well.

Right, will fix.

Quoted 3 lines

I would have expected to see a hidden BR2_LINUX_KERNEL_FORMAT with the text strings "zImage", "bzImage", "uImage", .. - That can then be used as the make target.

Why not. But I must confess that I find this computation of values inside Config.in files a bit ugly: some values are computed in Config.in files, some in the makefile rules directly. But here too, if you insist on having this, I'll go ahead and implement it, as I don't have a very strong opinion on this.

Quoted 5 lines

Thomas> +# Get the real Linux version, which tells us where kernel modules are
Thomas> +# going to be installed in the target filesystem.
Thomas> +LINUX26_VERSION_PROBED = $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) --no-print-directory -s kernelrelease

We typically use $(shell ..)

Will do.

Quoted 10 lines

Thomas> +# Download
Thomas> +$(LINUX26_DIR)/.stamp_downloaded:
Thomas> + @$(call MESSAGE,"Downloading kernel")
Thomas> + $(call DOWNLOAD,$(LINUX26_SITE),$(LINUX26_SOURCE))
Thomas> +ifeq ($(BR2_LINUX_KERNEL_PATCH),y) Thomas> +ifneq ($(findstring http://,$(LINUX26_PATCH)),)
Thomas> + $(call DOWNLOAD,$(dir $(LINUX26_PATCH)),$(notdir $(LINUX26_PATCH)))
Thomas> +else ifneq ($(findstring ftp://,$(LINUX26_PATCH)),)
Thomas> + $(call DOWNLOAD,$(dir $(LINUX26_PATCH)),$(notdir $(LINUX26_PATCH)))

Quoted 2 lines

You can combine these using $(filter) - E.G.:
ifneq ($(filter http:// ftp://,$(LINUX26_PATCH)),)

Will do.

Quoted 4 lines

Thomas> +else ifeq ($(shell test -d $(LINUX26_PATCH) && echo "dir"),dir)
Thomas> + toolchain/patch-kernel.sh $(@D) $(LINUX26_PATCH) linux-*.patch

You have to escape the * - E.G. linux-\*.patch

Will do again :-)

Quoted 17 lines

Thomas> +else
Thomas> + toolchain/patch-kernel.sh $(@D) $(dir $(LINUX26_PATCH)) $(notdir $(LINUX26_PATCH))
Thomas> +endif
Thomas> +endif
Thomas> + $(Q)touch $@
Thomas> +
Thomas> +
Thomas> +# Configuration
Thomas> +$(LINUX26_DIR)/.stamp_configured: $(LINUX26_DIR)/.stamp_patched
Thomas> + @$(call MESSAGE,"Configuring kernel")
Thomas> +ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
Thomas> + $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
Thomas> +else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM),y)
Thomas> + cp $(BR2_LINUX_KERNEL_CUSTOM_FILE) $(@D)/.config
Thomas> + yes "" | $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig

Quoted 4 lines

Hmm, why the yes '' here and not for defconfig? I would prefer to get rid of it, so the user is in control (they can always use the yes ''|make stuff on the BR commandline if they want unattended builds, like I do for buildbot).

So as by default not to have questions that could stop the build. In general, I don't see doing "yes '' | make oldconfig" as a way of hiding errors, as by default, oldconfig uses the default choice for every configuration item, and this default choice usually makes sense.

Quoted 3 lines

Why not simply $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) $(LINUX26_FORMAT) where LINUX26_FORMAT is uImage/zImage/bzImage? That's afaik how it used to be done.

make uImage only builds the uImage kernel image. make with no arguments builds the default kernel image (zImage in the ARM case) and also builds the modules.

So we could also do :

make uImage
make modules

but in any case, we have two make targets to call.

Quoted 8 lines

Thomas> +# Installation
Thomas> +$(LINUX26_DIR)/.stamp_installed: $(LINUX26_DIR)/.stamp_compiled
Thomas> + @$(call MESSAGE,"Installing kernel")
Thomas> + cp $(LINUX26_IMAGE_PATH) $(BINARIES_DIR)
Thomas> + $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) \
Thomas> + INSTALL_MOD_PATH=$(TARGET_DIR) modules_install

Does that do something sane with a nonmodular kernel?

No, will fix.

Quoted 1 line

You're good at this one ;)

Will fix too :-)

Thanks a lot!

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#4 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Thomas> +config BR2_LINUX_KERNEL_CUSTOM_STABLE
Thomas> + bool "Custom stable version"

Quoted 2 lines
Quoted 2 lines

I would drop "stable" here.

Thomas> Why ? Only stable releases, i.e releases available in Thomas> http://kernel.org/pub/linux/kernel/v2.6/ are supported. And in this Thomas> directory, only stable releases are available.

Well, "stable" has different meanings to different people. When I think of stable in regard to kernels, I think of the stable at kernel.org releases (E.G. 2.6.x.y).

For the kernel headers we simply call it

"Linux 2.6 (manually specified version)"

Thomas> +
Thomas> +config BR2_LINUX_KERNEL_CUSTOM_TARBALL
Thomas> + bool "Custom tarball"
Thomas> +

Quoted 3 lines
Quoted 3 lines

What about the same-as-kernel-headers choice? Or perhaps the fixed version should used that?

Thomas> I could add another option to say ? same version as kernel headers ?. Thomas> However, I'd prefer to keep the "BR2_LINUX_KERNEL_2_6_34" option as it Thomas> is: remember that in the external toolchain case, ? same version as Thomas> kernel headers ? doesn't make sense.

Ok. You could hide the option if !internal toolchain.

Quoted 5 lines
Quoted 5 lines

I think it would be nicer to do something like what you're doing with BR2_LINUX_KERNEL_PATCH_LOCATION - E.G. make it autodetect if it's a defconfig in the kernel tree or an external file. You can either do this using $(wildcard ..) (to check if the file exists), or simply check for slashes in the string $(findstring /,..).

Thomas> Why not, but I would find the semantic of the option rather strange, Thomas> and there might be corner cases where deciding whether it is a Thomas> defconfig name or the patch to a configuration file would be difficult.

Quoted 1 line
Quoted 1 line

From an user perspective, I think it's clearer to have two separate

Thomas> options for this, rather than a single option with a strange semantic Thomas> which requires looking at the help text to understand what it actually Thomas> does.

Thomas> But of course, if you insist on having this, I'll implement it, no big Thomas> deal.

No, just leave it, I don't feel strongly about it.

Quoted 3 lines
Quoted 3 lines

I would have expected to see a hidden BR2_LINUX_KERNEL_FORMAT with the text strings "zImage", "bzImage", "uImage", .. - That can then be used as the make target.

Thomas> Why not. But I must confess that I find this computation of values Thomas> inside Config.in files a bit ugly: some values are computed in Thomas> Config.in files, some in the makefile rules directly. But here too, if Thomas> you insist on having this, I'll go ahead and implement it, as I don't Thomas> have a very strong opinion on this.

Well, only add it if you need the text string for something (E.G. the make target). If you prefer doing it in make, then that's fine as well - It's not something that needs to change often.

In general I think it makes sense to keep these things in Kconfig when you need to keep several lines in sync, and otherwise don't need to change anything in .mk files (E.G. when adding new kernel headers, busybox versions, ..).

Thomas> +# Configuration
Thomas> +$(LINUX26_DIR)/.stamp_configured: $(LINUX26_DIR)/.stamp_patched
Thomas> + @$(call MESSAGE,"Configuring kernel")
Thomas> +ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
Thomas> + $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
Thomas> +else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM),y)
Thomas> + cp $(BR2_LINUX_KERNEL_CUSTOM_FILE) $(@D)/.config
Thomas> + yes "" | $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig

Quoted 5 lines
Quoted 5 lines

Hmm, why the yes '' here and not for defconfig? I would prefer to get rid of it, so the user is in control (they can always use the yes ''|make stuff on the BR commandline if they want unattended builds, like I do for buildbot).

Thomas> So as by default not to have questions that could stop the build. In Thomas> general, I don't see doing "yes '' | make oldconfig" as a way of hiding Thomas> errors, as by default, oldconfig uses the default choice for every Thomas> configuration item, and this default choice usually makes sense.

The point is that it isn't consistent. We don't do this for uclibc/busybox, and you don't do it for defconfigs in the kernel tree (which often are also slightly outdated).

Quoted 3 lines
Quoted 3 lines

Why not simply $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) $(LINUX26_FORMAT) where LINUX26_FORMAT is uImage/zImage/bzImage? That's afaik how it used to be done.

Thomas> make uImage only builds the uImage kernel image. make with no arguments Thomas> builds the default kernel image (zImage in the ARM case) and also Thomas> builds the modules.

This seems platform/arch specific. On PPC, the default image is typically uImage, so make with no arguments builds uImage and modules.

Does this mean that the existing advanced linux support is broken on ARM/uImage when using a modular kernel? - There it looks like it just calls 'make uImage'. I always use a nonmodular kernel, so I never noticed.

Thomas> So we could also do :

Thomas> make uImage
Thomas> make modules

Probably better to do make; make <format> (where format is uImage/zImage/bzImage/..)

As make modules errors out with something like:

The present kernel configuration has modules disabled. Type 'make config' and enable loadable module support. Then build a kernel with module support enabled.

make: *** [modules] Error 1

Thomas> but in any case, we have two make targets to call.

Yes.

Signature · 1 line
Bye, Peter Korsgaard
#5 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Quoted 3 lines · On Sat, 19 Jun 2010 21:48:20 +0200 Peter Korsgaard <[email protected]> wrote:

Well, "stable" has different meanings to different people. When I think of stable in regard to kernels, I think of the stable at kernel.org releases (E.G. 2.6.x.y).

Ah, I see. For me, 2.6.x versions are also stable versions, by oppposition with -rc versions. But ok, I've changed this.

Quoted 6 lines

Thomas> I could add another option to say ? same version as kernel headers ?. Thomas> However, I'd prefer to keep the "BR2_LINUX_KERNEL_2_6_34" option as it Thomas> is: remember that in the external toolchain case, ? same version as Thomas> kernel headers ? doesn't make sense.

Ok. You could hide the option if !internal toolchain.

Sure, done.

Quoted 8 lines

Well, only add it if you need the text string for something (E.G. the make target). If you prefer doing it in make, then that's fine as well - It's not something that needs to change often.

In general I think it makes sense to keep these things in Kconfig when you need to keep several lines in sync, and otherwise don't need to change anything in .mk files (E.G. when adding new kernel headers, busybox versions, ..).

Ok. I haven't changed this part for now.

Quoted 3 lines

The point is that it isn't consistent. We don't do this for uclibc/busybox, and you don't do it for defconfigs in the kernel tree (which often are also slightly outdated).

Ok, I got rid of it.

Quoted 11 lines

Thomas> make uImage only builds the uImage kernel image. make with no arguments Thomas> builds the default kernel image (zImage in the ARM case) and also Thomas> builds the modules.

This seems platform/arch specific. On PPC, the default image is typically uImage, so make with no arguments builds uImage and modules.

Does this mean that the existing advanced linux support is broken on ARM/uImage when using a modular kernel? - There it looks like it just calls 'make uImage'. I always use a nonmodular kernel, so I never noticed.

The current advanced thing does "make modules ; make modules_install" when CONFIG_MODULES is enabled.

Quoted 4 lines

Thomas> make uImage
Thomas> make modules

Probably better to do make; make <format> (where format is uImage/zImage/bzImage/..)

Isn't this what I'm doing already ?

Regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#6 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 3 lines
Quoted 3 lines

Well, "stable" has different meanings to different people. When I think of stable in regard to kernels, I think of the stable at kernel.org releases (E.G. 2.6.x.y).

Thomas> Ah, I see. For me, 2.6.x versions are also stable versions, by Thomas> oppposition with -rc versions. But ok, I've changed this.

Ok - Notice that there isn't anything stopping people from using a -rc version (and there shouldn't be) - E.G.

http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Quoted 3 lines
Quoted 3 lines

The point is that it isn't consistent. We don't do this for uclibc/busybox, and you don't do it for defconfigs in the kernel tree (which often are also slightly outdated).

Thomas> Ok, I got rid of it.

Thanks.

Quoted 4 lines
Quoted 4 lines

Does this mean that the existing advanced linux support is broken on ARM/uImage when using a modular kernel? - There it looks like it just calls 'make uImage'. I always use a nonmodular kernel, so I never noticed.

Thomas> The current advanced thing does "make modules ; make modules_install" Thomas> when CONFIG_MODULES is enabled.

Ok, that makes sense.

Thomas> make uImage
Thomas> make modules

Quoted 2 lines
Quoted 2 lines

Probably better to do make; make <format> (where format is uImage/zImage/bzImage/..)

Thomas> Isn't this what I'm doing already ?

No, you were doing:

+# Compilation
+$(LINUX26_DIR)/.stamp_compiled: $(LINUX26_DIR)/.stamp_configured
+ @$(call MESSAGE,"Compiling kernel")
+ $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D)
+ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
+ $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) uImage
+endif
+ $(Q)touch $@

E.G. just make (followed by make uImage if uImage is selected).

I guess we should do:

make <format>
if modules:
make modules
make modules-install

Signature · 1 line
Bye, Peter Korsgaard
#7 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Hello,

Quoted 4 lines · On Sun, 20 Jun 2010 19:51:23 +0200 Peter Korsgaard <[email protected]> wrote:

Ok - Notice that there isn't anything stopping people from using a -rc version (and there shouldn't be) - E.G.

http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Nothing prevents people from doing this, but in that case they have to use the "Custom tarball" option and give the full URL.

The "Custom version" only works with versions that are available directly in http://www.kernel.org/pub/linux/kernel/v2.6/.

Quoted 13 lines

Thomas> Isn't this what I'm doing already ?

No, you were doing:

linux/linux.mk new file +8 -0
+# Compilation
+$(LINUX26_DIR)/.stamp_compiled: $(LINUX26_DIR)/.stamp_configured
+	@$(call MESSAGE,"Compiling kernel")
+	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D)
+ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
+	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) uImage
+endif
+	$(Q)touch $@
Quoted 8 lines

E.G. just make (followed by make uImage if uImage is selected).

I guess we should do:

make <format>
if modules:
make modules
make modules-install

I have separate build and install steps. Would something like the following be OK for you ?

* build step
make <format>
if modules:
make modules

* install step

	cp .... $(BINARIES_DIR)
	if modules:
		make modules_install

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#8 lore raw

PATCH 1/10 New, simpler, infrastructure for building the Linux kernel

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Thomas> Hello,
Thomas> On Sun, 20 Jun 2010 19:51:23 +0200

Quoted 4 lines · Thomas> Peter Korsgaard <[email protected]> wrote:
Quoted 4 lines

Ok - Notice that there isn't anything stopping people from using a -rc version (and there shouldn't be) - E.G.

http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Thomas> Nothing prevents people from doing this, but in that case they have to Thomas> use the "Custom tarball" option and give the full URL.

Thomas> The "Custom version" only works with versions that are available Thomas> directly in http://www.kernel.org/pub/linux/kernel/v2.6/.

Ahh yes, sorry about the noise then.

Thomas> I have separate build and install steps. Would something like the Thomas> following be OK for you ?

Thomas> * build step
Thomas> make <format>
Thomas> if modules:
Thomas> make modules

Thomas> * install step
Thomas> cp .... $(BINARIES_DIR)
Thomas> if modules:
Thomas> make modules_install

Yes, that sounds good.

Signature · 1 line
Bye, Peter Korsgaard
#9 lore raw

PATCH 2/10 Remove old Linux infrastructure

In reply to Thomas Petazzoni
---
 Makefile                          |    4 -
 target/Makefile.in                |   16 --
 target/linux/Config.in            |   33 ---
 target/linux/Config.in.advanced   |  463 --------------------------------
 target/linux/Config.in.versions   |   62 -----
 target/linux/Makefile.in          |  250 -----------------
 target/linux/Makefile.in.advanced |  532 -------------------------------------
 7 files changed, 0 insertions(+), 1360 deletions(-)
 delete mode 100644 target/linux/Config.in
 delete mode 100644 target/linux/Config.in.advanced
 delete mode 100644 target/linux/Config.in.versions
 delete mode 100644 target/linux/Makefile.in
 delete mode 100644 target/linux/Makefile.in.advanced
Makefile +0 -4
index a72dc80..d04c6e3 100644
@@ -308,10 +308,6 @@ else ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
 include toolchain/*/*.mk
 endif
 
-ifeq ($(BR2_PACKAGE_LINUX),y)
-TARGETS+=linux26-modules
-endif
-
 include package/*/*.mk
 
 TARGETS+=target-finalize
target/Makefile.in +0 -16
index 8feb564..9a75116 100644
@@ -1,7 +1,3 @@
-BR2_PACKAGE_LINUX_FORMAT:=$(call qstrip,$(BR2_PACKAGE_LINUX_FORMAT))
-BR2_PACKAGE_LINUX_KCONFIG:=$(call qstrip,$(BR2_PACKAGE_LINUX_KCONFIG))
-
-
 # COPY_FILE absolute_path_to_file, target_directory, filename
 ifneq ($(call qstrip,$(BUILDROOT_COPYTO)),)	# Use shell definition
 define COPY_FILE
@@ -56,16 +52,4 @@ include target/generic/Makefile.in
 include target/device/Makefile.in
 include target/xtensa/Makefile.in
 
-# kernel rules
-# We already did add the kernel target to TARGETS and now just pull in the rules
-# to actually build this target.
-
-ifeq ($(BR2_KERNEL_LINUX),y)
-include target/linux/Makefile.in
-endif
-
-ifeq ($(BR2_KERNEL_LINUX_ADVANCED),y)
-include target/linux/Makefile.in.advanced
-endif
-
 include target/device/Makefile.in.linux
target/linux/Config.in deleted +0 -33
deleted file mode 100644
index c79fca2..0000000
@@ -1,33 +0,0 @@
-#comment "Linux kernel options"
-
-if BR2_KERNEL_LINUX
-config BR2_PACKAGE_LINUX_KCONFIG
-	string ".config file"
-	depends on BR2_PACKAGE_LINUX
-	default ""
-	help
-	  kernel's .config to use to build a kernel for the target.
-
-	  If the above setting is empty, you can change the default
-	  board-imposed value by passing LINUX26_KCONFIG=<path> to
-	  make.
-
-config BR2_PACKAGE_LINUX_FORMAT
-	string "kernel binary format"
-	depends on BR2_PACKAGE_LINUX
-	default ""
-	help
-	  kernel binary format.
-	  Popular values include:
-	  - bzImage
-	  - zImage
-	  and other, architecture dependant formats.
-
-	  Note that the default format is supposed to be set by your
-	  board-description, if any.
-	  i386 and compatible default to bzImage if nothing was given
-	  above.
-	  If the above setting is empty, you can change the default
-	  board-imposed value by passing LINUX26_FORMAT=<string> to
-	  make.
-endif
target/linux/Config.in.advanced deleted +0 -463

463 lines not on this page · raw message

target/linux/Config.in.versions deleted +0 -62

62 lines not on this page · raw message

target/linux/Makefile.in deleted +0 -250

250 lines not on this page · raw message

target/linux/Makefile.in.advanced deleted +0 -532

532 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#10 lore raw

PATCH 3/10 iso9660: take into account the linux changes

In reply to Thomas Petazzoni
---
 fs/iso9660/Config.in  |    4 ++--
 fs/iso9660/iso9660.mk |    6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)
fs/iso9660/Config.in +2 -2
index 7830581..5f7cdf4 100644
@@ -1,7 +1,7 @@
 config BR2_TARGET_ROOTFS_ISO9660
 	bool "iso image"
 	depends on BR2_i386
-	depends on !BR2_KERNEL_none
+	depends on BR2_LINUX_KERNEL
 	select BR2_TARGET_ROOTFS_EXT2
 	select BR2_TARGET_GRUB
 	help
@@ -13,4 +13,4 @@ config BR2_TARGET_ROOTFS_ISO9660_BOOT_MENU
 	default "fs/iso9660/menu.lst"
 
 comment "iso image requires a Linux kernel to be built"
-	depends on BR2_i386 && BR2_KERNEL_none
+	depends on BR2_i386 && !BR2_LINUX_KERNEL
fs/iso9660/iso9660.mk +3 -3
index 66e2de2..6f60893 100644
@@ -15,14 +15,14 @@ ifeq ($(BR2_TARGET_ROOTFS_ISO9660_SQUASH),y)
 ISO9660_OPTS+=-U
 endif
 
-$(BINARIES_DIR)/rootfs.iso9660: host-cdrkit host-fakeroot $(LINUX_KERNEL) $(BINARIES_DIR)/rootfs.ext2 grub
+$(BINARIES_DIR)/rootfs.iso9660: host-cdrkit host-fakeroot linux26 ext2-root grub
 	@$(call MESSAGE,"Generating root filesystem image rootfs.iso9660")
 	mkdir -p $(ISO9660_TARGET_DIR)
 	mkdir -p $(ISO9660_TARGET_DIR)/boot/grub
 	cp $(GRUB_DIR)/stage2/stage2_eltorito $(ISO9660_TARGET_DIR)/boot/grub/
 	cp $(ISO9660_BOOT_MENU) $(ISO9660_TARGET_DIR)/boot/grub/menu.lst
-	cp $(LINUX_KERNEL) $(ISO9660_TARGET_DIR)/kernel
-	cp $(EXT2_TARGET) $(ISO9660_TARGET_DIR)/initrd
+	cp $(LINUX26_IMAGE_PATH) $(ISO9660_TARGET_DIR)/kernel
+	cp $(BINARIES_DIR)/rootfs.ext2 $(ISO9660_TARGET_DIR)/initrd
 	# Use fakeroot to pretend all target binaries are owned by root
 	rm -f $(FAKEROOT_SCRIPT)
 	touch $(BUILD_DIR)/.fakeroot.00000
Signature · 1 line
1.7.0.4
#11 lore raw

PATCH 3/10 iso9660: take into account the linux changes

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Thomas> Signed-off-by: Thomas Petazzoni <[email protected]> Thomas> ---

 Thomas>  fs/iso9660/Config.in  |    4 ++--
 Thomas>  fs/iso9660/iso9660.mk |    6 +++---

Thomas> 2 files changed, 5 insertions(+), 5 deletions(-)

Thomas> diff --git a/fs/iso9660/Config.in b/fs/iso9660/Config.in Thomas> index 7830581..5f7cdf4 100644
Thomas> --- a/fs/iso9660/Config.in
Thomas> +++ b/fs/iso9660/Config.in
Thomas> @@ -1,7 +1,7 @@

 Thomas>  config BR2_TARGET_ROOTFS_ISO9660
 Thomas>  	bool "iso image"
 Thomas>  	depends on BR2_i386
 Thomas> -	depends on !BR2_KERNEL_none
 Thomas> +	depends on BR2_LINUX_KERNEL
 Thomas>  	select BR2_TARGET_ROOTFS_EXT2
 Thomas>  	select BR2_TARGET_GRUB
 Thomas>  	help

Thomas> @@ -13,4 +13,4 @@ config BR2_TARGET_ROOTFS_ISO9660_BOOT_MENU
Thomas> default "fs/iso9660/menu.lst"

Thomas> comment "iso image requires a Linux kernel to be built"
Thomas> - depends on BR2_i386 && BR2_KERNEL_none
Thomas> + depends on BR2_i386 && !BR2_LINUX_KERNEL

I know you're not the author of this, but any reason this shouldn't work on x86-64 as well?

Signature · 1 line
Bye, Peter Korsgaard
#12 lore raw

PATCH 4/10 module-init-tools: remove support for cross-depmod

In reply to Thomas Petazzoni

The new infrastructure to build the Linux kernel doesn't use a cross-depmod. This isn't needed with modern module-init-tools that most distros include perfectly handle this.

---
 package/module-init-tools/module-init-tools.mk |   44 ------------------------
 1 files changed, 0 insertions(+), 44 deletions(-)
package/module-init-tools/module-init-tools.mk +0 -44
index 129770e..8adb684 100644
@@ -70,50 +70,6 @@ module-init-tools-dirclean:
 	rm -rf $(MODULE_INIT_TOOLS_DIR)
 
 #############################################################
-
-
-$(MODULE_INIT_TOOLS_DIR2)/.source: $(DL_DIR)/$(MODULE_INIT_TOOLS_SOURCE)
-	$(MODULE_INIT_TOOLS_CAT) $(DL_DIR)/$(MODULE_INIT_TOOLS_SOURCE) | tar -C $(TOOLCHAIN_DIR) -xvf -
-	toolchain/patch-kernel.sh $(MODULE_INIT_TOOLS_DIR2) package/module-init-tools \*.patch
-	$(CONFIG_UPDATE) $(MODULE_INIT_TOOLS_DIR2)
-	touch $(MODULE_INIT_TOOLS_DIR2)/.source
-
-$(MODULE_INIT_TOOLS_DIR2)/.configured: $(MODULE_INIT_TOOLS_DIR2)/.source
-	(cd $(MODULE_INIT_TOOLS_DIR2); \
-		CC="$(HOSTCC)" \
-		./configure $(QUIET) \
-		--target=$(GNU_TARGET_NAME) \
-		--host=$(GNU_HOST_NAME) \
-		--build=$(GNU_HOST_NAME) \
-		--sysconfdir=/etc \
-		--program-transform-name='' \
-	)
-	touch $(MODULE_INIT_TOOLS_DIR2)/.configured
-
-$(MODULE_INIT_TOOLS_DIR2)/$(MODULE_INIT_TOOLS_BINARY): $(MODULE_INIT_TOOLS_DIR2)/.configured
-	$(MAKE) -C $(MODULE_INIT_TOOLS_DIR2)
-	touch -c $(MODULE_INIT_TOOLS_DIR2)/$(MODULE_INIT_TOOLS_BINARY)
-
-
-$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26: $(MODULE_INIT_TOOLS_DIR2)/$(MODULE_INIT_TOOLS_BINARY)
-	$(INSTALL) -D $(MODULE_INIT_TOOLS_DIR2)/$(MODULE_INIT_TOOLS_BINARY) $(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26
-
-cross-depmod26: $(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26
-
-module-init-tools-source cross-depmod26-source: $(DL_DIR)/$(MODULE_INIT_TOOLS_SOURCE)
-
-cross-depmod26-clean:
-	rm -f $(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26
-	-$(MAKE) -C $(MODULE_INIT_TOOLS_DIR2) clean
-
-cross-depmod26-dirclean:
-	rm -rf $(MODULE_INIT_TOOLS_DIR2)
-
-ifeq ($(BR2_PACKAGE_LINUX),y)
-HOST_SOURCE+=module-init-tools-source
-endif
-
-#############################################################
 #
 ## Toplevel Makefile options
 #
Signature · 1 line
1.7.0.4
#13 lore raw

PATCH 5/10 module-init-tools: bump version + convert to autotools

In reply to Thomas Petazzoni

The "remove-index" patch is no longer needed, the newer version of module-init-tools correctly uses strchr().

The "module-init-tools" patch, whose main purpose was to disable the generation of man pages (it requires docbook2man), is replaced by a simpler implementation, module-init-tools-3.11-add-manpages-config-option.patch.

---
 ...nit-tools-3.11-add-manpages-config-option.patch |   47 ++++++++++++
 .../module-init-tools-remove-index.patch           |   12 ---
 package/module-init-tools/module-init-tools.mk     |   80 +++-----------------
 package/module-init-tools/module-init-tools.patch  |   77 -------------------
 4 files changed, 57 insertions(+), 159 deletions(-)
 create mode 100644 package/module-init-tools/module-init-tools-3.11-add-manpages-config-option.patch
 delete mode 100644 package/module-init-tools/module-init-tools-remove-index.patch
 delete mode 100644 package/module-init-tools/module-init-tools.patch
package/module-init-tools/module-init-tools-3.11-add-manpages-config-option.patch new file +47 -0
new file mode 100644
index 0000000..28f51de
@@ -0,0 +1,47 @@
+Disable manual pages generation when docbook2man is not available.
+
+Signed-off-by: Thomas Petazzoni <[email protected]>
+---
+ Makefile.am  |    7 ++++++-
+ configure.ac |    7 +++----
+ 2 files changed, 9 insertions(+), 5 deletions(-)
+
+Index: module-init-tools-3.11/Makefile.am
+===================================================================
+--- module-init-tools-3.11.orig/Makefile.am
++++ module-init-tools-3.11/Makefile.am
+@@ -39,7 +39,12 @@
+ MAN5 = modprobe.conf.5 modules.dep.5 depmod.conf.5 modprobe.d.5
+ MAN8 = depmod.8 insmod.8 lsmod.8 rmmod.8 modprobe.8 modinfo.8
+ SGML = $(addprefix doc/,  $(MAN5:%.5=%.sgml) $(MAN8:%.8=%.sgml))
+-dist_man_MANS = $(MAN5) $(MAN8)
++
++if HAVE_DOCBOOKTOMAN
++MANPAGES  = $(MAN5) $(MAN8)
++endif
++dist_man_MANS = $(MANPAGES)
++
+ # If they haven't overridden mandir, fix it (never /man!)
+ mandir =$(shell if [ @mandir@ = $(prefix)/man ]; then if [ $(prefix) = / ]; then echo /usr/share/man; else echo $(prefix)/share/man; fi; else echo @mandir@; fi)
+ 
+Index: module-init-tools-3.11/configure.ac
+===================================================================
+--- module-init-tools-3.11.orig/configure.ac
++++ module-init-tools-3.11/configure.ac
+@@ -29,13 +29,12 @@
+ AC_PROG_CC
+ AC_PROG_RANLIB
+ 
+-AC_CHECK_PROGS(DOCBOOKTOMAN, docbook-to-man docbook2man, [no],)
+-if test x"$DOCBOOKTOMAN" = xno
++AC_CHECK_PROGS(DOCBOOKTOMAN, docbook-to-man docbook2man)
++if test x"$DOCBOOKTOMAN" = x
+ then
+ 	AC_MSG_WARN([docbook2man not found])
+-	# fail with a meaningfull error if $DOCBOOKTOMAN called by the makefile
+-	DOCBOOKTOMAN=docbook2man
+ fi
++AM_CONDITIONAL([HAVE_DOCBOOKTOMAN], [test "x$DOCBOOKTOMAN" != "x"])
+  
+ # Delay adding the zlib_flags until after AC_PROG_CC, so we can distinguish
+ # between a broken cc and a working cc but missing libz.a.
package/module-init-tools/module-init-tools-remove-index.patch deleted +0 -12
deleted file mode 100644
index 1a2da28..0000000
@@ -1,12 +0,0 @@
-diff -ur module-init-tools-3.2.2/modprobe.c module-init-tools-3.2.2-patched/modprobe.c
---- module-init-tools-3.2.2/modprobe.c	2005-12-01 17:42:09.000000000 -0600
-+++ module-init-tools-3.2.2-patched/modprobe.c	2006-12-04 19:50:50.353237649 -0600
-@@ -270,7 +270,7 @@
- 	char *modname;
- 
- 	/* Ignore lines without : or which start with a # */
--	ptr = index(line, ':');
-+	ptr = strchr(line, ':');
- 	if (ptr == NULL || line[strspn(line, "\t ")] == '#')
- 		return 0;
- 
package/module-init-tools/module-init-tools.mk +10 -70

87 lines not on this page · raw message

package/module-init-tools/module-init-tools.patch deleted +0 -77

77 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#14 lore raw

PATCH 5/10 module-init-tools: bump version + convert to autotools

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Thomas> The "remove-index" patch is no longer needed, the newer version of Thomas> module-init-tools correctly uses strchr().

Thomas> The "module-init-tools" patch, whose main purpose was to disable the Thomas> generation of man pages (it requires docbook2man), is replaced by a Thomas> simpler implementation,
Thomas> module-init-tools-3.11-add-manpages-config-option.patch.

Looks good, don't forget to send upstream.

Signature · 1 line
Bye, Peter Korsgaard
#15 lore raw

PATCH 6/10 linux: Add dependency on host-module-init-tools

In reply to Thomas Petazzoni

In order to not depend on module init tools being installed on the development environment of the Buildroot user, let's build module init tools for the host.

---
 linux/linux.mk                                 |    2 +-
 package/module-init-tools/module-init-tools.mk |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)
linux/linux.mk +1 -1
index 39abdea..d3a583e 100644
@@ -113,7 +113,7 @@ $(LINUX26_DIR)/.stamp_installed: $(LINUX26_DIR)/.stamp_compiled
 	rm -f $(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_PROBED)/source
 	$(Q)touch $@
 
-linux26: $(LINUX26_DEPENDENCIES) $(LINUX26_DIR)/.stamp_installed
+linux26: host-module-init-tools $(LINUX26_DEPENDENCIES) $(LINUX26_DIR)/.stamp_installed
 
 ifeq ($(BR2_LINUX_KERNEL),y)
 TARGETS+=linux26
package/module-init-tools/module-init-tools.mk +2 -0
index 3e8b06b..ea7c014 100644
@@ -17,3 +17,5 @@ MODULE_INIT_TOOLS_AUTORECONF=YES
 HOST_MODULE_INIT_TOOLS_AUTORECONF=YES
 
 $(eval $(call AUTOTARGETS,package,module-init-tools))
+$(eval $(call AUTOTARGETS,package,module-init-tools,host))
+
Signature · 1 line
1.7.0.4
#16 lore raw

PATCH 7/10 Add generic functions to enable/set/disable options in kconfig files

In reply to Thomas Petazzoni

The KCONFIG_ENABLE_OPT, KCONFIG_SET_OPT and KCONFIG_DISABLE_OPT are new make functions to respectively enable, set and disable options in Kconfig-like files (as used by the kernel, uClibc or Busybox).

They can be used as follows :

$(call KCONFIG_ENABLE_OPT,CONFIG_FOOBAR,/path/to/.config) $(call KCONFIG_SET_OPT,CONFIG_BARFOO,foobar,/path/to/.config) $(call KCONFIG_DISABLE_OPT,CONFIG_FARBOO,/path/to/.config)

---
 package/Makefile.package.in |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)
package/Makefile.package.in +15 -0
index cdf49f8..b702c49 100644
@@ -40,6 +40,21 @@ UPPERCASE = $(strip $(eval __tmp := $1) \
 			$(__tmp)))) \
      $(__tmp))
 
+define KCONFIG_ENABLE_OPT
+       $(SED) "/$(1)/d" $(2)
+       echo "$(1)=y" >> $(2)
+endef
+
+define KCONFIG_SET_OPT
+       $(SED) "/$(1)/d" $(3)
+       echo "$(1)=$(2)" >> $(3)
+endef
+
+define KCONFIG_DISABLE_OPT
+       $(SED) "/$(1)/d" $(2)
+       echo "# $(1) is not set" >> $(2)
+endef
+
 # Define extrators for different archive suffixes
 INFLATE.bz2 = $(BZCAT)
 INFLATE.gz  = $(ZCAT)
Signature · 1 line
1.7.0.4
#17 lore raw

PATCH 8/10 linux: adjust kernel config according to the Buildroot configuration

In reply to Thomas Petazzoni

We only adjust the configuration or ARM EABI and IPv6. The (more complicated) initramfs case is handled in a separate commit. The user is expected to take care of all other configuration details (like having Netfilter enabled to make iptables work, etc.)

---
 linux/linux.mk |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)
linux/linux.mk +12 -0
index d3a583e..4cdc304 100644
@@ -90,6 +90,18 @@ else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM),y)
 	cp $(BR2_LINUX_KERNEL_CUSTOM_FILE) $(@D)/.config
 	yes "" | $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig
 endif
+ifeq ($(BR2_ARM_EABI),y)
+	$(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config)
+	$(call KCONFIG_DISABLE_OPT,CONFIG_OABI_COMPAT,$(@D)/.config)
+else
+	$(call KCONFIG_DISABLE_OPT,CONFIG_AEABI,$(@D)/.config)
+endif
+ifeq ($(BR2_INET_IPV6),y)
+	$(call KCONFIG_ENABLE_OPT,CONFIG_IPV6,$(@D)/.config)
+else
+	$(call KCONFIG_DISABLE_OPT,CONFIG_IPV6,$(@D)/.config)
+endif
+	yes "" | $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig 2>&1 >/dev/null
 	$(Q)touch $@
 
 # Compilation
Signature · 1 line
1.7.0.4
#18 lore raw

PATCH 8/10 linux: adjust kernel config according to the Buildroot configuration

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Thomas> We only adjust the configuration or ARM EABI and IPv6. The (more

s/or/of/.

Thomas> complicated) initramfs case is handled in a separate commit. The user Thomas> is expected to take care of all other configuration details (like Thomas> having Netfilter enabled to make iptables work, etc.)

Thomas> Signed-off-by: Thomas Petazzoni <[email protected]> Thomas> ---

 Thomas>  linux/linux.mk |   12 ++++++++++++

Thomas> 1 files changed, 12 insertions(+), 0 deletions(-)

Thomas> diff --git a/linux/linux.mk b/linux/linux.mk Thomas> index d3a583e..4cdc304 100644
Thomas> --- a/linux/linux.mk
Thomas> +++ b/linux/linux.mk
Thomas> @@ -90,6 +90,18 @@ else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM),y)

 Thomas>  	cp $(BR2_LINUX_KERNEL_CUSTOM_FILE) $(@D)/.config
 Thomas>  	yes "" | $(MAKE1) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig
 Thomas>  endif

Thomas> +ifeq ($(BR2_ARM_EABI),y)
Thomas> + $(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config)
Thomas> + $(call KCONFIG_DISABLE_OPT,CONFIG_OABI_COMPAT,$(@D)/.config)
Thomas> +else
Thomas> + $(call KCONFIG_DISABLE_OPT,CONFIG_AEABI,$(@D)/.config)

I'm not sure I like this hardcoded policy. What if the user wants to run some precompiled OABI binaries together with his EABI rootfs?

Thomas> +endif
Thomas> +ifeq ($(BR2_INET_IPV6),y)
Thomas> + $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6,$(@D)/.config)
Thomas> +else
Thomas> + $(call KCONFIG_DISABLE_OPT,CONFIG_IPV6,$(@D)/.config)
Thomas> +endif
Thomas> + yes "" | $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig 2>&1 >/dev/null

The yes shouldn't be needed, and I don't like hiding errors.

Signature · 1 line
Bye, Peter Korsgaard
#19 lore raw

PATCH 8/10 linux: adjust kernel config according to the Buildroot configuration

Quoted 2 lines · On Fri, 18 Jun 2010 21:43:10 +0200 Peter Korsgaard <[email protected]> wrote:

I'm not sure I like this hardcoded policy. What if the user wants to run some precompiled OABI binaries together with his EABI rootfs?

I don't really like this hardcoded policy either, but I kept what existed before.

What should we do ? Just not modify the kernel configuration, except for the initramfs case ? Isn't the EABI thing going to hit a large number of users, coming back with a "my Busybox init doesn't start" question ?

Quoted 9 lines

Thomas> +endif
Thomas> +ifeq ($(BR2_INET_IPV6),y)
Thomas> + $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6,$(@D)/.config)
Thomas> +else
Thomas> + $(call KCONFIG_DISABLE_OPT,CONFIG_IPV6,$(@D)/.config)
Thomas> +endif
Thomas> + yes "" | $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig 2>&1 >/dev/null

The yes shouldn't be needed, and I don't like hiding errors.

It does not hide errors, it uses the default choice for every unset option :-)

But ok, if you don't like it, why not.

Regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#20 lore raw

PATCH 8/10 linux: adjust kernel config according to the Buildroot configuration

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 2 lines
Quoted 2 lines

I'm not sure I like this hardcoded policy. What if the user wants to run some precompiled OABI binaries together with his EABI rootfs?

Thomas> I don't really like this hardcoded policy either, but I kept what Thomas> existed before.

Thomas> What should we do ? Just not modify the kernel configuration, except Thomas> for the initramfs case ? Isn't the EABI thing going to hit a large Thomas> number of users, coming back with a "my Busybox init doesn't start" Thomas> question ?

I find the EABI one ok, but the COMPAT thing is afaik just an optimization, it doesn't really harm to have it enabled.

Thomas> + yes "" | $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig 2>&1 >/dev/null

Quoted 2 lines
Quoted 2 lines

The yes shouldn't be needed, and I don't like hiding errors.

Thomas> It does not hide errors, it uses the default choice for every unset Thomas> option :-)

It's the 2>&1 >/dev/null that I don't like - That does hide errors.

Signature · 1 line
Bye, Peter Korsgaard

A message that is not in the archive (sent off-list or not yet received): [email protected]

#22 lore raw

PATCH 8/10 linux: adjust kernel config according to the Buildroot configuration

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Nataraj" == Nataraj S Narayan <[email protected]> writes:

Nataraj> Hi
Nataraj> I was using? atmel patched kernel 2.6.30 on at91sam9263 Sbc with Nataraj> CONFIG_OABI_COMPAT=y default.? But when disabled, my freepascal ( Nataraj> ww.freepascal.org) binanies wouldnt work.

Nataraj> Maybe fcp dont generate? fully EABI for arm-uclibc.

Ok, please send your mails to the list instead of directly to me so Thomas can also see it.

Signature · 1 line
Bye, Peter Korsgaard
#23 lore raw

PATCH 9/10 linux: add support for linux26-{menuconfig, xconfig, gconfig} targets

In reply to Thomas Petazzoni

These targets allow the user to customize the configuration of the Linux kernel. After changing the kernel configuration, the next time the user runs "make", the kernel is rebuilt to take into account the new configuration (not rebuilt from scratch).

---
 linux/linux.mk |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)
linux/linux.mk +6 -2
index 4cdc304..05a95af 100644
@@ -104,8 +104,9 @@ endif
 	yes "" | $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig 2>&1 >/dev/null
 	$(Q)touch $@
 
-# Compilation
-$(LINUX26_DIR)/.stamp_compiled: $(LINUX26_DIR)/.stamp_configured
+# Compilation. We make sure the kernel gets rebuilt when the
+# configuration has changed.
+$(LINUX26_DIR)/.stamp_compiled: $(LINUX26_DIR)/.stamp_configured $(LINUX26_DIR)/.config
 	@$(call MESSAGE,"Compiling kernel")
 	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D)
 ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
@@ -127,6 +128,9 @@ $(LINUX26_DIR)/.stamp_installed: $(LINUX26_DIR)/.stamp_compiled
 
 linux26: host-module-init-tools $(LINUX26_DEPENDENCIES) $(LINUX26_DIR)/.stamp_installed
 
+linux26-menuconfig linux26-xconfig linux26-gconfig: $(LINUX26_DIR)/.stamp_configured
+	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) $(subst linux26-,,$@)
+
 ifeq ($(BR2_LINUX_KERNEL),y)
 TARGETS+=linux26
 endif
\ No newline at end of file
Signature · 1 line
1.7.0.4
#24 lore raw

PATCH 10/10 linux: add support for initramfs

In reply to Thomas Petazzoni

In Buildroot, the kernel is built and installed *before* the root filesystems are built. This allows the root filesystem to correctly contain the kernel modules that have been installed.

However, in the initramfs case, the root filesystem is part of the kernel. Therefore, the kernel should be built *after* the root filesystem (which, in the initramfs case simply builds a text file listing all files/directories/devices/symlinks that should be part of the initramfs). However, this isn't possible as the initramfs text file would lack all kernel modules.

So, the solution choosen here is to keep the normal order: kernel is built before the root filesystem is generated, and to add a little quirk to retrigger a kernel compilation after the root filesystem generation.

To do so, we add a ROOTFS_$(FSTYPE)_POST_TARGETS variable to the fs/common.mk infrastructure. This allows individual filesystems to set a target name that we should depend on *after* generating the root filesystem itself (contrary to normal ROOTFS_$(FSTYPE)_DEPENDENCIES, on which we depend *before* generating the root filesystem).

The initramfs code in fs/initramfs/initramfs.mk uses this to add a dependency on 'linux26-rebuild-with-initramfs'.

In linux/linux.mk, we do various things :

* If BR2_TARGET_ROOTFS_INITRAMFS is enabled (i.e if initramfs is enabled as a root filesystem type), then we create an empty rootfs.initramfs file (remember that at this point, the root filesystem hasn't been generated) and we adjust the kernel configuration to include an initramfs. Of course, in the initial kernel build, this initramfs will be empty.

* In the linux26-rebuild-with-initramfs target, we retrigger a compilation of the kernel image, after removing the initramfs in the kernel sources to make sure it gets properly rebuilt (we've experienced cases were modifying the rootfs.initramfs file wouldn't retrigger the generation of the initramfs at the kernel level).

This is fairly quirky, but initramfs really is a special case, so in one way or another, we need a little quirk to solve its specialness.

---
 fs/common.mk              |    6 +++++-
 fs/initramfs/initramfs.mk |    2 ++
 linux/linux.mk            |   33 +++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 1 deletions(-)
fs/common.mk +5 -1
index 50dc974..74e9ce0 100644
@@ -19,6 +19,10 @@
 #  ROOTFS_$(FSTYPE)_POST_GEN_HOOKS, a list of hooks to call after
 #  generating the filesystem image
 #
+#  ROOTFS_$(FSTYPE)_POST_TARGETS, the list of targets that should be
+#  run after running the main filesystem target. This is useful for
+#  initramfs, to rebuild the kernel once the initramfs is generated.
+#
 # In terms of configuration option, this macro assumes that the
 # BR2_TARGET_ROOTFS_$(FSTYPE) config option allows to enable/disable
 # the generation of a filesystem image of a particular type. If
@@ -60,7 +64,7 @@ endif
 $(1)-root-show-depends:
 	@echo $(ROOTFS_$(2)_DEPENDENCIES) host-fakeroot host-makedevs $(if $(BR2_TARGET_ROOTFS_$(2)_LZMA),host-lzma)
 
-$(1)-root: $(BINARIES_DIR)/rootfs.$(1)
+$(1)-root: $(BINARIES_DIR)/rootfs.$(1) $(ROOTFS_$(2)_POST_TARGETS)
 
 ifeq ($$(BR2_TARGET_ROOTFS_$(2)),y)
 TARGETS += $(1)-root
fs/initramfs/initramfs.mk +2 -0
index 3e81567..e6d004e 100644
@@ -23,4 +23,6 @@ define ROOTFS_INITRAMFS_CMD
 	$(SHELL) fs/initramfs/gen_initramfs_list.sh -u 0 -g 0 $(TARGET_DIR) > $$@
 endef
 
+ROOTFS_INITRAMFS_POST_TARGETS += linux26-rebuild-with-initramfs
+
 $(eval $(call ROOTFS_TARGET,initramfs))
\ No newline at end of file
linux/linux.mk +33 -0
index 05a95af..1c32c86 100644
@@ -101,6 +101,19 @@ ifeq ($(BR2_INET_IPV6),y)
 else
 	$(call KCONFIG_DISABLE_OPT,CONFIG_IPV6,$(@D)/.config)
 endif
+ifeq ($(BR2_TARGET_ROOTFS_INITRAMFS),y)
+	# As the kernel gets compiled before root filesystems are
+	# built, we create a fake initramfs file list. It'll be
+	# replaced later by the real list, and the kernel will be
+	# rebuilt using the linux26-rebuild-with-initramfs target.
+	touch $(BINARIES_DIR)/rootfs.initramfs
+	$(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_INITRD,$(@D)/.config)
+	$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,\"$(BINARIES_DIR)/rootfs.initramfs\",$(@D)/.config)
+	$(call KCONFIG_ENABLE_OPT,CONFIG_INITRAMFS_COMPRESSION_GZIP,$(@D)/.config)
+else
+	$(call KCONFIG_DISABLE_OPT,CONFIG_BLK_DEV_INITRD,$(@D)/.config)
+	$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,\"\",$(@D)/.config)
+endif
 	yes "" | $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) oldconfig 2>&1 >/dev/null
 	$(Q)touch $@
 
@@ -131,6 +144,26 @@ linux26: host-module-init-tools $(LINUX26_DEPENDENCIES) $(LINUX26_DIR)/.stamp_in
 linux26-menuconfig linux26-xconfig linux26-gconfig: $(LINUX26_DIR)/.stamp_configured
 	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) $(subst linux26-,,$@)
 
+# Support for rebuilding the kernel after the initramfs file list has
+# been generated in $(BINARIES_DIR)/rootfs.initramfs.
+$(LINUX26_DIR)/.stamp_initramfs_rebuilt: $(LINUX26_DIR)/.stamp_installed $(BINARIES_DIR)/rootfs.initramfs
+	@$(call MESSAGE,"Rebuilding kernel with initramfs")
+	# Remove the previously generated initramfs which was empty,
+	# to make sure the kernel will actually regenerate it.
+	$(RM) -f $(@D)/usr/initramfs_data.cpio.*
+	# Build the kernel.
+	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D)
+ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
+	$(MAKE) $(LINUX26_MAKE_FLAGS) -C $(@D) uImage
+endif
+	# Copy the kernel image to its final destination
+	cp $(LINUX26_IMAGE_PATH) $(BINARIES_DIR)
+	$(Q)touch $@
+
+# The initramfs building code must make sure this target gets called
+# after it generated the initramfs list of files.
+linux26-rebuild-with-initramfs: $(LINUX26_DIR)/.stamp_initramfs_rebuilt
+
 ifeq ($(BR2_LINUX_KERNEL),y)
 TARGETS+=linux26
 endif
\ No newline at end of file
Signature · 1 line
1.7.0.4
#25 lore raw
In reply to Thomas Petazzoni
Quoted 8 lines

-----Original Message-----
From: buildroot-bounces at busybox.net [mailto:buildroot- bounces at busybox.net] On Behalf Of Thomas Petazzoni
Sent: Monday, 14 June 2010 4:50 AM
To: buildroot at uclibc.org
Cc: Thomas Petazzoni
Subject: [Buildroot] [pull request] Pull request for branch linux-cleanup

Quoted 4 lines

Hello,

Here is a set of 10 patches that completely rewrites the Linux kernel compilation process in Buildroot. It is supposed to be applied on top of

the

Quoted 3 lines

bootloaders-cleanup branch I've sent yesterday.

I've fairly drastically reduced the number of options to configure the

kernel,

Quoted 1 line

and particulary removed the horrible mess of version selection. See the

first

Quoted 1 line

commit in this branch for what remains in terms of configuration options

for

Quoted 2 lines

the kernel. As I've removed quite a few things, I'm interested to know how you're using Buildroot to build your kernel, and whether this proposal

still

Quoted 1 line

matches your use cases.

Looks good to me. The only comment I have is I liked the old automatic kernel patching from kernel.org, but now you need to know what the latest version is. No big deal though.

Cheers,
Paul.

#26 lore raw
In reply to Thomas Petazzoni

Hello,

Quoted 11 lines · On Sun, 13 Jun 2010 20:50:04 +0200 Thomas Petazzoni…

Here is a set of 10 patches that completely rewrites the Linux kernel compilation process in Buildroot. It is supposed to be applied on top of the bootloaders-cleanup branch I've sent yesterday.

I've fairly drastically reduced the number of options to configure the kernel, and particulary removed the horrible mess of version selection. See the first commit in this branch for what remains in terms of configuration options for the kernel. As I've removed quite a few things, I'm interested to know how you're using Buildroot to build your kernel, and whether this proposal still matches your use cases.

Quoted 2 lines

Peter: for me, this patch set is ready for inclusion, unless there are comments, of course.

I've done the following changes :

* Rebased on top of master, now that the bootloaders-cleanup branch has been merged. As the linux-cleanup branch was initially based on bootloaders-cleanup, this rebase did not require any change in the code.

* Added a new commit that deletes target/Config.in which is now longer used/needed.

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#27 lore raw
In reply to Thomas Petazzoni
Quoted 11 lines · On Sun, 13 Jun 2010 20:50:04 +0200 Thomas Petazzoni…

Here is a set of 10 patches that completely rewrites the Linux kernel compilation process in Buildroot. It is supposed to be applied on top of the bootloaders-cleanup branch I've sent yesterday.

I've fairly drastically reduced the number of options to configure the kernel, and particulary removed the horrible mess of version selection. See the first commit in this branch for what remains in terms of configuration options for the kernel. As I've removed quite a few things, I'm interested to know how you're using Buildroot to build your kernel, and whether this proposal still matches your use cases.

Quoted 2 lines

Peter: for me, this patch set is ready for inclusion, unless there are comments, of course.

I've pushed a newer version, with the following changes since the previous post :

* Provide a "same as kernel headers" choice for the version selection

* Use "depends on" instead of an "if...endif" block when a single option needs to be conditionnaly shown

* Merge BR2_LINUX_KERNEL_PATCH and BR2_LINUX_KERNEL_PATCH_LOCATION into a single option. When the option value is empty, not patch is applied. When the option value is non empty, it is considered as a path or URL to a patch to be applied to the kernel.

* Rename BR2_LINUX_KERNEL_USE_CUSTOM to
BR2_LINUX_KERNEL_USE_CUSTOM_FILE.

* Fix the default value for the kernel binary format: BR2_i386 instead of BR2_386 and bzImage by default on BR2_x86_64.

* Use BR2_KERNEL_MIRROR where appropriate

* Use the $(shell...) construct instead of back-quotes

* Use $(filter ...) instead of multiple $(findstring ...)

* Fix escaping of linux-*.patch -> linux-\*.patch

* Remove yes "" | make oldconfig constructs

* Install the modules only if CONFIG_MODULES is enabled

* Add newline at the end of linux.mk.

* Add $(TARGET_MAKE_ENV) to $(MAKE) invocations so that a PATH containing $(HOST_DIR)/usr/bin is used when building the kernel. This is needed in order to allow the kernel to find mkimage and other host tools (module-init-tools). This fixes the problem reported by Ossy.

* Rename option mentioning "stable" so as to not use the "stable" wording since it could be confusing for users.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#28 lore raw
Quoted 33 lines · On Sun, 20 Jun 2010 15:37:16 +0200 Thomas Petazzoni…

I've pushed a newer version, with the following changes since the previous post :

* Provide a "same as kernel headers" choice for the version selection

* Use "depends on" instead of an "if...endif" block when a single option needs to be conditionnaly shown

* Merge BR2_LINUX_KERNEL_PATCH and BR2_LINUX_KERNEL_PATCH_LOCATION into a single option. When the option value is empty, not patch is applied. When the option value is non empty, it is considered as a path or URL to a patch to be applied to the kernel.

* Rename BR2_LINUX_KERNEL_USE_CUSTOM to
BR2_LINUX_KERNEL_USE_CUSTOM_FILE.

* Fix the default value for the kernel binary format: BR2_i386 instead of BR2_386 and bzImage by default on BR2_x86_64.

* Use BR2_KERNEL_MIRROR where appropriate

* Use the $(shell...) construct instead of back-quotes

* Use $(filter ...) instead of multiple $(findstring ...)

* Fix escaping of linux-*.patch -> linux-\*.patch

* Remove yes "" | make oldconfig constructs

* Install the modules only if CONFIG_MODULES is enabled

* Add newline at the end of linux.mk.

Quoted 8 lines

* Add $(TARGET_MAKE_ENV) to $(MAKE) invocations so that a PATH containing $(HOST_DIR)/usr/bin is used when building the kernel. This is needed in order to allow the kernel to find mkimage and other host tools (module-init-tools). This fixes the problem reported by Ossy.

* Rename option mentioning "stable" so as to not use the "stable" wording since it could be confusing for users.

And also :

* Enable OABI compatibility as well as EABI when EABI is enabled in Buildroot configuration

* Enable iso9660 when BR2_x86_64 is the architecture.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#29 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Thomas> And also :

Thomas> * Enable OABI compatibility as well as EABI when EABI is enabled in
Thomas> Buildroot configuration

Didn't we just agree that we shouldn't touch the compat option? People might have good reasons (compatibility) to enable it or not (size).

Signature · 1 line
Bye, Peter Korsgaard
#30 lore raw
Quoted 2 lines · On Sun, 20 Jun 2010 19:52:44 +0200 Peter Korsgaard <[email protected]> wrote:

Didn't we just agree that we shouldn't touch the compat option? People might have good reasons (compatibility) to enable it or not (size).

Ah, ok, I misunderstood. Fixed in my tree, will be part of the next push. I'll let you know when it's ready.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#31 lore raw
Quoted 2 lines · On Sun, 20 Jun 2010 21:22:48 +0200 Thomas Petazzoni…

Ah, ok, I misunderstood. Fixed in my tree, will be part of the next push. I'll let you know when it's ready.

The next (and hopefully final) push has been made. Changes since the last one :

* Do not touch the OABI_COMPAT kernel option

* At compile time do :
make <image-type>
if modules:
make modules

At install time do :

	cp <image-path> $(BINARIES_DIR)
	if modules:
		make modules_install

At initramfs regeneration time do :
make <image-type>

* Minor Config.in improvements (tabulations, help texts, etc.)

As usual, available in the linux-cleanup branch at
git://git.busybox.net/~tpetazzoni/git/buildroot.

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#32 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Thomas> On Sun, 20 Jun 2010 21:22:48 +0200

Quoted 2 lines · Thomas> Thomas Petazzoni <[email protected]> wrote:
Quoted 2 lines

Ah, ok, I misunderstood. Fixed in my tree, will be part of the next push. I'll let you know when it's ready.

Thomas> The next (and hopefully final) push has been made. Changes since the Thomas> last one :

Thanks, pulled and pushed.

I think we need to update the defconfigs having kernel builds enabled. Will you do it, or should I?

Signature · 1 line
Bye, Peter Korsgaard