linux: fix using extensions (branch yem/kernel-ext)
v2 cover linux: fix using extensions (branch yem/kernel-ext)
Hello All!
This small series is an attempt at fixing the use of extensions, which broke unnoticeably since we switched to using the kconfig-package infrastructure for the linux package.
- patches 1-2: introduce patch-dependencies (code and manual)
- patch 3 : actually fix the extensions
- patches 4-5: simplify adding new extensions
Changes v1 -> v2:
- introduce patch-dependencies (Thomas P.)
- use that instead of custom-written rules on .stamp_patched
- split out the 'extensions infra' from the actual extensions fix
Regards,
Yann E. MORIN.
The following changes since commit 3fd2c4d25f727c5364e52abf65c37f19fe461433:
iotop: new package (2015-03-13 23:16:38 +0100)
are available in the git repository at:
git://git.busybox.net/~ymorin/git/buildroot yem/kernel-ext
for you to fetch changes up to 724c084b0e9f1d98670184ab5e77a2381e04d67c:
linux: migrate extensions to use the new infrastructure (2015-03-14 15:19:31 +0100)
----------------------------------------------------------------
Yann E. MORIN (5):
package infra: add patch-dependencies docs/manual: add _PATCH_DEPENDENCIES
linux: fix extensions
linux: simplify adding new extensions
linux: migrate extensions to use the new infrastructure
docs/manual/adding-packages-generic.txt | 9 +++++++++ linux/linux-ext-fbtft.mk | 8 +------- linux/linux-ext-rtai.mk | 8 +------- linux/linux-ext-xenomai.mk | 8 +------- linux/linux.mk | 7 +++++++ package/pkg-generic.mk | 9 ++++++++- 6 files changed, 27 insertions(+), 22 deletions(-)
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/5 package infra: add patch-dependencies
Some packages need to vampirise files from one or more other packages. This is the case, for example, of the Linux kernel and its /extensions/.
Add a new type of dependencies, that are guaranteed to be extracted and patched before a package is patched.
--- package/pkg-generic.mk | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
package/pkg-generic.mk +8 -1
@@ -427,6 +427,7 @@ endif # Eliminate duplicates in dependencies $(2)_FINAL_DEPENDENCIES = $$(sort $$($(2)_DEPENDENCIES)) +$(2)_FINAL_PATCH_DEPENDENCIES = $$(sort $$($(2)_PATCH_DEPENDENCIES)) $(2)_INSTALL_STAGING ?= NO $(2)_INSTALL_IMAGES ?= NO
@@ -538,6 +539,8 @@ $$($(2)_TARGET_CONFIGURE): $$($(2)_TARGET_PATCH) $(1)-patch: $$($(2)_TARGET_PATCH) $$($(2)_TARGET_PATCH): $$($(2)_TARGET_EXTRACT) +# Order-only dependency +$$($(2)_TARGET_PATCH): | $$(patsubst %,%-patch,$$($(2)_FINAL_PATCH_DEPENDENCIES)) $(1)-extract: $$($(2)_TARGET_EXTRACT) $$($(2)_TARGET_EXTRACT): $$($(2)_TARGET_SOURCE)
@@ -568,8 +571,12 @@ endif $(1)-show-version: @echo $$($(2)_VERSION) -$(1)-show-depends: +$(1)-show-build-depends: @echo $$($(2)_FINAL_DEPENDENCIES) +$(1)-show-patch-depends: + @echo $$($(2)_FINAL_PATCH_DEPENDENCIES) +$(1)-show-depends: + @echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$($(2)_FINAL_PATCH_DEPENDENCIES)) $(1)-graph-depends: graph-depends-requirements @$$(INSTALL) -d $$(O)/graphs
Signature · 1 line
1.9.1
PATCH v2 1/5 package infra: add patch-dependencies
Hi Yann, All
Rather than dropping reviewed and tested tag without a word, I prefer to write what I understand.
I tested the series up to patch 3/5 with xenomai extension.
Le 14/03/2015 15:25, Yann E. MORIN a ?crit :
Quoted 17 lines
Some packages need to vampirise files from one or more other packages. This is the case, for example, of the Linux kernel and its /extensions/.
Add a new type of dependencies, that are guaranteed to be extracted and patched before a package is patched.
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>--- package/pkg-generic.mk | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)package/pkg-generic.mk +0
-0
package/pkg-generic.mk endif · line 430
Quoted 4 lines
package/pkg-generic.mk +1
-0@@ -427,6 +427,7 @@ endif # Eliminate duplicates in dependencies $(2)_FINAL_DEPENDENCIES = $$(sort $$($(2)_DEPENDENCIES)) +$(2)_FINAL_PATCH_DEPENDENCIES = $$(sort $$($(2)_PATCH_DEPENDENCIES))
After patch 3/5 applied and if xenomai extension is selected, we have "xenomai" in LINUX_FINAL_PATCH_DEPENDENCIES.
package/pkg-generic.mk $$($(2)_TARGET_CONFIGURE): $$($(2)_TARGET_PATCH) · line 543
Quoted 9 lines
package/pkg-generic.mk +2
-0$(2)_INSTALL_STAGING ?= NO $(2)_INSTALL_IMAGES ?= NO@@ -538,6 +539,8 @@ $$($(2)_TARGET_CONFIGURE): $$($(2)_TARGET_PATCH) $(1)-patch: $$($(2)_TARGET_PATCH) $$($(2)_TARGET_PATCH): $$($(2)_TARGET_EXTRACT) +# Order-only dependency +$$($(2)_TARGET_PATCH): | $$(patsubst %,%-patch,$$($(2)_FINAL_PATCH_DEPENDENCIES))
Here LINUX_TARGET_PATCH is appended with xenomai-patch, so linux-patch can start as soon as xenomai-patch is done.
'|' is used to not restart the build for each make invocation.
Quoted 4 lines
package/pkg-generic.mk +0
-0$(1)-extract: $$($(2)_TARGET_EXTRACT) $$($(2)_TARGET_EXTRACT): $$($(2)_TARGET_SOURCE)
package/pkg-generic.mk endif · line 579
Quoted 10 lines
package/pkg-generic.mk +5
-1@@ -568,8 +571,12 @@ endif $(1)-show-version: @echo $$($(2)_VERSION) -$(1)-show-depends: +$(1)-show-build-depends: @echo $$($(2)_FINAL_DEPENDENCIES) +$(1)-show-patch-depends: + @echo $$($(2)_FINAL_PATCH_DEPENDENCIES) +$(1)-show-depends: + @echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$($(2)_FINAL_PATCH_DEPENDENCIES))
Here LINUX_FINAL_PATCH_DEPENDENCIES is taken into account for linux-show-depends
Before and after the patch 3/5 the result is the same for linux-show-depends:
make O=test/xenomai/ linux-show-depends
host-kmod host-lzop toolchain xenomai
After the patch 3/5, we can see that xenomai is no longer part of build dependencies.
make O=test/xenomai/ linux-show-build-depends
host-kmod host-lzop toolchain
But it's now a patch dependencies:
make O=test/xenomai/ linux-show-patch-depends
xenomai
package/pkg-generic.mk endif
Quoted 4 lines
package/pkg-generic.mk +0
-0$(1)-graph-depends: graph-depends-requirements @$$(INSTALL) -d $$(O)/graphs
So,
Best regards,
Romain
PATCH v2 1/5 package infra: add patch-dependencies
In reply to Yann E. MORINDear Yann E. MORIN,
package/pkg-generic.mk endif · line 579
Quoted 7 lines · Yann E. MORIN
-$(1)-show-depends:
+$(1)-show-build-depends:package/pkg-generic.mk +4
-0@echo $$($(2)_FINAL_DEPENDENCIES) +$(1)-show-patch-depends: + @echo $$($(2)_FINAL_PATCH_DEPENDENCIES) +$(1)-show-depends: + @echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$($(2)_FINAL_PATCH_DEPENDENCIES))
I think this will break graph-depends. The python script will do "make <foo>-show-depends" for each package. Now this will return things such as "xenomai-patch", so the script will then try to do "make xenomai-patch-show-depends" to recurse into the dependency tree, and this will fail. <pkg>-show-depends should only return the name of packages.
Also, I'm not sure about the usefulness of having separate show-build-depends and show-patch-depends. It could have been useful if show-depends would simply depend on them, but it doesn't work because we want all dependencies space-separated on one line.
So, what about replacing this part with just:
$(1)-show-depends:
@echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$(patsubst %-patch,%,$$($(2)_FINAL_PATCH_DEPENDENCIES)))
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/5 package infra: add patch-dependencies
Thomas, All,
On 2015-04-04 15:47 +0200, Thomas Petazzoni spake thusly:
Quoted 4 lines
Dear Yann E. MORIN,
On Sat, 14 Mar 2015 15:25:17 +0100, Yann E. MORIN wrote:
Quoted 11 lines
package/pkg-generic.mk endif · line 579
Quoted 7 lines
-$(1)-show-depends:
+$(1)-show-build-depends:package/pkg-generic.mk +4
-0@echo $$($(2)_FINAL_DEPENDENCIES) +$(1)-show-patch-depends: + @echo $$($(2)_FINAL_PATCH_DEPENDENCIES) +$(1)-show-depends: + @echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$($(2)_FINAL_PATCH_DEPENDENCIES))I think this will break graph-depends. The python script will do "make <foo>-show-depends" for each package. Now this will return things such as "xenomai-patch"
No, I don't think so, because _PATCH_DEPENDENCIES contain package names, not or internal make targets. And I can prove it:
$ make linux-show-depends
fbtft host-kmod host-lzop toolchainwhere fbtft is a kernel extension.
Have you even tried it? ;-p
Quoted 9 lines
Also, I'm not sure about the usefulness of having separate show-build-depends and show-patch-depends. It could have been useful if show-depends would simply depend on them, but it doesn't work because we want all dependencies space-separated on one line.
So, what about replacing this part with just:
$(1)-show-depends:
@echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$(patsubst %-patch,%,$$($(2)_FINAL_PATCH_DEPENDENCIES)))
Well, I don;t mind getting rid of the separate show-{build,patch}-depends rules. But your proposal is wrong, since we do not have to get rid of the trailing -patch, because it's not in there...
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/5 package infra: add patch-dependencies
Dear Yann E. MORIN,
Quoted 11 lines · Yann E. MORIN
Quoted 3 lines
I think this will break graph-depends. The python script will do "make <foo>-show-depends" for each package. Now this will return things such as "xenomai-patch"
No, I don't think so, because
_PATCH_DEPENDENCIEScontain package names, not or internal make targets. And I can prove it:$ make linux-show-depends fbtft host-kmod host-lzop toolchainwhere fbtft is a kernel extension.
Yes, sorry, Romain explained to me on IRC where I was wrong.
Quoted 1 line
Have you even tried it? ;-p
No, I only did a review.
Quoted 3 lines
Well, I don;t mind getting rid of the separate show-{build,patch}-depends rules. But your proposal is wrong, since we do not have to get rid of the trailing -patch, because it's not in there...
Correct. I believe the show-{build,patch}-depends are not useful, though.
I'll apply this series.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/5 package infra: add patch-dependencies
In reply to Yann E. MORINQuoted 34 lines · Yann E. MORIN
Some packages need to vampirise files from one or more other packages. This is the case, for example, of the Linux kernel and its /extensions/.
Add a new type of dependencies, that are guaranteed to be extracted and patched before a package is patched.
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>--- package/pkg-generic.mk | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)package/pkg-generic.mk +3
-0@@ -427,6 +427,7 @@ endif # Eliminate duplicates in dependencies $(2)_FINAL_DEPENDENCIES = $$(sort $$($(2)_DEPENDENCIES)) +$(2)_FINAL_PATCH_DEPENDENCIES = $$(sort $$($(2)_PATCH_DEPENDENCIES)) $(2)_INSTALL_STAGING ?= NO $(2)_INSTALL_IMAGES ?= NO@@ -538,6 +539,8 @@ $$($(2)_TARGET_CONFIGURE): $$($(2)_TARGET_PATCH) $(1)-patch: $$($(2)_TARGET_PATCH) $$($(2)_TARGET_PATCH): $$($(2)_TARGET_EXTRACT) +# Order-only dependency +$$($(2)_TARGET_PATCH): | $$(patsubst %,%-patch,$$($(2)_FINAL_PATCH_DEPENDENCIES)) $(1)-extract: $$($(2)_TARGET_EXTRACT) $$($(2)_TARGET_EXTRACT): $$($(2)_TARGET_SOURCE)
package/pkg-generic.mk endif · line 579
Quoted 10 lines
package/pkg-generic.mk +5
-1@@ -568,8 +571,12 @@ endif $(1)-show-version: @echo $$($(2)_VERSION) -$(1)-show-depends: +$(1)-show-build-depends: @echo $$($(2)_FINAL_DEPENDENCIES) +$(1)-show-patch-depends: + @echo $$($(2)_FINAL_PATCH_DEPENDENCIES) +$(1)-show-depends: + @echo $$(sort $$($(2)_FINAL_DEPENDENCIES) $$($(2)_FINAL_PATCH_DEPENDENCIES))
I just noticed now: you added the patch dependencies to show-depends, but not
to -all-source, -all-external-deps and -all-legal-info. Isn't that wrong? Of course, at the moment it makes no difference because it's only used for linux extension packages and in that case the linux package is always selected anyway so it'll end up in $(TARGETS) and get printed that way. But it just feels a bit inconsistent.
Regards,
Arnout
Quoted 4 lines
package/pkg-generic.mk +0
-0$(1)-graph-depends: graph-depends-requirements @$$(INSTALL) -d $$(O)/graphs
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v2 2/5 docs/manual: add _PATCH_DEPENDENCIES
In reply to Yann E. MORIN--- docs/manual/adding-packages-generic.txt | 9 +++++++++ 1 file changed, 9 insertions(+)
docs/manual/adding-packages-generic.txt +9 -0
@@ -304,6 +304,15 @@ information is (assuming the package name is +libfoo+) : a similar way, +HOST_LIBFOO_DEPENDENCIES+ lists the dependencies for the current host package. +* +LIBFOO_PATCH_DEPENDENCIES+ lists the dependencies (in terms of + package name) that are required for the current package to be + patched. These dependencies are guaranteed to be extracted and + patched before the current package is patched. In a similar way, + +HOST_LIBFOO_PATCH_DEPENDENCIES+ lists the dependencies for the + current host package. + This is seldom used; usually, +LIBFOO_DEPENDENCIES+ is what you + really want to use. + * +LIBFOO_PROVIDES+ lists all the virtual packages +libfoo+ is an implementation of. See xref:virtual-package-tutorial[].
Signature · 1 line
1.9.1
PATCH v2 2/5 docs/manual: add _PATCH_DEPENDENCIES
Hi Yann, all,
Le 14/03/2015 15:25, Yann E. MORIN a ?crit :
Quoted 17 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>--- docs/manual/adding-packages-generic.txt | 9 +++++++++ 1 file changed, 9 insertions(+)docs/manual/adding-packages-generic.txt +2
-0@@ -304,6 +304,15 @@ information is (assuming the package name is +libfoo+) : a similar way, +HOST_LIBFOO_DEPENDENCIES+ lists the dependencies for the current host package. +* +LIBFOO_PATCH_DEPENDENCIES+ lists the dependencies (in terms of + package name) that are required for the current package to be
docs/manual/adding-packages-generic.txt information is (assuming the package name is +libfoo+) : · line 318
Quoted 10 lines
docs/manual/adding-packages-generic.txt +7
-0+ patched. These dependencies are guaranteed to be extracted and + patched before the current package is patched. In a similar way, + +HOST_LIBFOO_PATCH_DEPENDENCIES+ lists the dependencies for the + current host package. + This is seldom used; usually, +LIBFOO_DEPENDENCIES+ is what you + really want to use. + * +LIBFOO_PROVIDES+ lists all the virtual packages +libfoo+ is an implementation of. See xref:virtual-package-tutorial[].
Best regards,
Romain
PATCH v2 3/5 linux: fix extensions
In reply to Yann E. MORINSince the move to the kconfig-package infra, linux extensions are broken.
In our linux package, extensions are applied as pre-patch hooks.
Before the kconfig-package infra, we had custom rules for the linux-*config targets, which were of the form:
linux-menuconfig: linux-configure
$(MAKE) -C $(LINUX_DIR) menuconfigThis caused the linux tree to be fully configured before running the configurators, and thus linux dependencies were entirely fullfilled, and extensions were properly applied.
Since we migrated (in dff25ea), the kconfig-package infra introduces a (hidden, internal) intermediate step 'kconfig-fixup' and decorelates the kconfig-part of the configuration from the actual package-part of the configuration:
linux-configure -------> kconfig-fixup --> .config --> $(LINUX_CONFIG_FILE)
/
linux-menuconfig --'As thus, this (very useful!) use-case breaks (starting from a clean Buildroot tree):
make menuconfig
-> enable a kernel and at least one extension
-> save and exit
make linux-menuconfig
-> extensions are not availableFix that by using the newly-introduced patch-dependencies, so that extensions are available before we try to patch the linux kernel.
--- linux/linux-ext-fbtft.mk | 2 +- linux/linux-ext-rtai.mk | 2 +- linux/linux-ext-xenomai.mk | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
linux/linux-ext-fbtft.mk +1 -1
@@ -6,7 +6,7 @@ ifeq ($(BR2_LINUX_KERNEL_EXT_FBTFT),y) # Add dependency to fbtft package (download helper for the fbtft source) -LINUX_DEPENDENCIES += fbtft +LINUX_PATCH_DEPENDENCIES += fbtft # for linux >= 3.15 install to drivers/video/fbdev/fbtft # for linux < 3.15 install to drivers/video/fbtft
linux/linux-ext-rtai.mk +1 -1
@@ -6,7 +6,7 @@ ifeq ($(BR2_LINUX_KERNEL_EXT_RTAI),y) # Add dependency to RTAI (user-space) which provide kernel patches -LINUX_DEPENDENCIES += rtai-patch +LINUX_PATCH_DEPENDENCIES += rtai RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))
linux/linux-ext-xenomai.mk +1 -1
@@ -6,7 +6,7 @@ ifeq ($(BR2_LINUX_KERNEL_EXT_XENOMAI),y) # Add dependency to xenomai (user-space) which provide ksrc part -LINUX_DEPENDENCIES += xenomai +LINUX_PATCH_DEPENDENCIES += xenomai # Adeos patch version XENOMAI_ADEOS_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH))
Signature · 1 line
1.9.1
PATCH v2 3/5 linux: fix extensions
Hi Yann, All
Le 14/03/2015 15:25, Yann E. MORIN a ?crit :
Quoted 33 lines
Since the move to the kconfig-package infra, linux extensions are broken.
In our linux package, extensions are applied as pre-patch hooks.
Before the kconfig-package infra, we had custom rules for the linux-*config targets, which were of the form:
linux-menuconfig: linux-configure $(MAKE) -C $(LINUX_DIR) menuconfigThis caused the linux tree to be fully configured before running the configurators, and thus linux dependencies were entirely fullfilled, and extensions were properly applied.
Since we migrated (in dff25ea), the kconfig-package infra introduces a (hidden, internal) intermediate step 'kconfig-fixup' and decorelates the kconfig-part of the configuration from the actual package-part of the configuration:
linux-configure -------> kconfig-fixup --> .config --> $(LINUX_CONFIG_FILE) / linux-menuconfig --'As thus, this (very useful!) use-case breaks (starting from a clean Buildroot tree):
make menuconfig -> enable a kernel and at least one extension -> save and exit make linux-menuconfig -> extensions are not available
Quoted 7 lines
Fix that by using the newly-introduced patch-dependencies, so that extensions are available before we try to patch the linux kernel.
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>---
I reproduced the issue with xenomai extension:
$ make O=test/xenomai/ linux-menuconfig [...] /home/naourr/git/buildroot/test/xenomai/build/xenomai-2.6.4/scripts/prepare-kernel.sh --linux=/home/naourr/git/buildroot/test/xenomai/build/linux-3.14.17 --arch=i386 --default --verbose make: /home/naourr/git/buildroot/test/xenomai/build/xenomai-2.6.4/scripts/prepare-kernel.sh : commande introuvable make: *** [/home/naourr/git/buildroot/test/xenomai/build/linux-3.14.17/.stamp_patched] Erreur 127
linux/linux-ext-xenomai.mk line 10
Quoted 11 lines
linux/linux-ext-xenomai.mk +1
-1@@ -6,7 +6,7 @@ ifeq ($(BR2_LINUX_KERNEL_EXT_XENOMAI),y) # Add dependency to xenomai (user-space) which provide ksrc part -LINUX_DEPENDENCIES += xenomai +LINUX_PATCH_DEPENDENCIES += xenomai
The issue is indeed fixed by this patch.
Best regard,
Romain
PATCH v2 4/5 linux: simplify adding new extensions
In reply to Yann E. MORINCurently, all three linux extensions follow the same layout:
- test if the extension is enabled
- add itself to linux' patch-dependencies
- declare a macro, added as the pre-patch hook
Except for the macro, all can be commonalised.
Add a simple infrastructure for that:
- extensions declare themselves in the list of extensions
- extensions define their macro
- the infra adds them to the patch-dependencies and pre-patch hooks as appropriate
--- linux/linux.mk | 7 +++++++ 1 file changed, 7 insertions(+)
linux/linux.mk +7 -0
@@ -333,6 +333,13 @@ endef # included here *must* be in the same directory! include $(sort $(wildcard linux/linux-ext-*.mk)) +LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\ + $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext))) + +LINUX_PRE_PATCH_HOOKS += $(foreach ext,$(LINUX_EXTENSIONS),\ + $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),\ + $(call UPPERCASE,$(ext))_PREPARE_KERNEL)) + $(eval $(kconfig-package)) # Support for rebuilding the kernel after the cpio archive has
Signature · 1 line
1.9.1
PATCH v2 4/5 linux: simplify adding new extensions
Hi Yann, All,
Le 14/03/2015 15:25, Yann E. MORIN a ?crit :
Quoted 28 lines
Curently, all three linux extensions follow the same layout:
- test if the extension is enabled
- add itself to linux' patch-dependencies
- declare a macro, added as the pre-patch hookExcept for the macro, all can be commonalised.
Add a simple infrastructure for that:
- extensions declare themselves in the list of extensions
- extensions define their macro
- the infra adds them to the patch-dependencies and pre-patch hooks as appropriateSigned-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>--- linux/linux.mk | 7 +++++++ 1 file changed, 7 insertions(+)linux/linux.mk +0
-0@@ -333,6 +333,13 @@ endef # included here *must* be in the same directory! include $(sort $(wildcard linux/linux-ext-*.mk))
linux/linux.mk endef · line 345
Quoted 10 lines
linux/linux.mk +7
-0+LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\ + $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext))) + +LINUX_PRE_PATCH_HOOKS += $(foreach ext,$(LINUX_EXTENSIONS),\ + $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),\ + $(call UPPERCASE,$(ext))_PREPARE_KERNEL)) + $(eval $(kconfig-package)) # Support for rebuilding the kernel after the cpio archive has
Tested with Xenomai extensions and obviously the patch 5/5 applied :)
Best regards,
Romain
PATCH v2 5/5 linux: migrate extensions to use the new infrastructure
In reply to Yann E. MORIN--- linux/linux-ext-fbtft.mk | 8 +------- linux/linux-ext-rtai.mk | 8 +------- linux/linux-ext-xenomai.mk | 8 +------- 3 files changed, 3 insertions(+), 21 deletions(-)
linux/linux-ext-fbtft.mk +1 -7
@@ -4,9 +4,7 @@ # Patch the linux kernel with fbtft extension ################################################################################ -ifeq ($(BR2_LINUX_KERNEL_EXT_FBTFT),y) -# Add dependency to fbtft package (download helper for the fbtft source) -LINUX_PATCH_DEPENDENCIES += fbtft +LINUX_EXTENSIONS += fbtft # for linux >= 3.15 install to drivers/video/fbdev/fbtft # for linux < 3.15 install to drivers/video/fbtft
@@ -22,7 +20,3 @@ define FBTFT_PREPARE_KERNEL >> $${dest}/Kconfig ; \ echo 'obj-y += fbtft/' >> $${dest}/Makefile endef - -LINUX_PRE_PATCH_HOOKS += FBTFT_PREPARE_KERNEL - -endif #BR2_LINUX_KERNEL_EXT_FBTFT
linux/linux-ext-rtai.mk +1 -7
@@ -4,9 +4,7 @@ # Patch the linux kernel with RTAI extension ################################################################################ -ifeq ($(BR2_LINUX_KERNEL_EXT_RTAI),y) -# Add dependency to RTAI (user-space) which provide kernel patches -LINUX_PATCH_DEPENDENCIES += rtai +LINUX_EXTENSIONS += rtai RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))
@@ -41,7 +39,3 @@ define RTAI_PREPARE_KERNEL $(notdir $(RTAI_PATCH)) endef endif - -LINUX_PRE_PATCH_HOOKS += RTAI_PREPARE_KERNEL - -endif #BR2_LINUX_EXT_RTAI
linux/linux-ext-xenomai.mk +1 -7
@@ -4,9 +4,7 @@ # Patch the linux kernel with xenomai extension ################################################################################ -ifeq ($(BR2_LINUX_KERNEL_EXT_XENOMAI),y) -# Add dependency to xenomai (user-space) which provide ksrc part -LINUX_PATCH_DEPENDENCIES += xenomai +LINUX_EXTENSIONS += xenomai # Adeos patch version XENOMAI_ADEOS_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH))
@@ -24,7 +22,3 @@ define XENOMAI_PREPARE_KERNEL $(XENOMAI_ADEOS_OPTS) \ --verbose endef - -LINUX_PRE_PATCH_HOOKS += XENOMAI_PREPARE_KERNEL - -endif #BR2_LINUX_EXT_XENOMAI
Signature · 1 line
1.9.1
PATCH v2 5/5 linux: migrate extensions to use the new infrastructure
Hi Yann, All,
Le 14/03/2015 15:25, Yann E. MORIN a ?crit :
Quoted 8 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>--- linux/linux-ext-fbtft.mk | 8 +------- linux/linux-ext-rtai.mk | 8 +------- linux/linux-ext-xenomai.mk | 8 +------- 3 files changed, 3 insertions(+), 21 deletions(-)
Tested with Xenomai extensions.
Best regards,
Romain
v2 cover linux: fix using extensions (branch yem/kernel-ext)
In reply to Yann E. MORINDear Yann E. MORIN,
Quoted 6 lines · Yann E. MORIN
Yann E. MORIN (5):
package infra: add patch-dependencies docs/manual: add_PATCH_DEPENDENCIES
linux: fix extensions
linux: simplify adding new extensions
linux: migrate extensions to use the new infrastructure
Thanks a lot, series applied!
I've only done one minor change: in the first patch, I got rid of show-build-depends and show-patch-depends, and kept only show-depends.
Thanks also to Romain who did review and test the patch series, it was definitely very useful.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com