[Buildroot] Linux extension from a BR2_EXTERNAL tree

[Buildroot] Linux extension from a BR2_EXTERNAL tree

[Thomas Petazzoni]

Hello,

I am trying to implement a Linux extension, which applies a bunch of
patches to the Linux kernel tree, as a package in a BR2_EXTERNAL tree.
So, I have a package in my BR2_EXTERNAL that does this:

ifeq ($(BR2_PACKAGE_MUSDK_MARVELL_KERNEL_PATCHES_APPLY),y)
LINUX_EXTENSIONS += musdk-marvell

ifeq ($(BR2_PACKAGE_MUSDK_MARVELL_KERNEL_PATCHES_LINUX),y)
MUSDK_MARVELL_KERNEL_PATCH_SERIES = linux
else ifeq ($(BR2_PACKAGE_MUSDK_MARVELL_KERNEL_PATCHES_LINUX_4_14),y)
MUSDK_MARVELL_KERNEL_PATCH_SERIES = linux-4.14
endif

define MUSDK_MARVELL_PREPARE_KERNEL
        $(APPLY_PATCHES) $(@D) $(MUSDK_MARVELL_DIR)/patches/$(MUSDK_MARVELL_KERNEL_PATCH_SERIES) *.patch
endef
endif

My package is properly listed in LINUX_PATCH_DEPENDENCIES:

$ make printvars VARS=LINUX_PATCH_DEPENDENCIES
LINUX_PATCH_DEPENDENCIES=           musdk-marvell

And in LINUX_PRE_PATCH_HOOKS:

$ make printvars VARS=LINUX_PRE_PATCH_HOOKS
LINUX_PRE_PATCH_HOOKS=            MUSDK_MARVELL_PREPARE_KERNEL

When I build the kernel, it does run the MUSDK_MARVELL_PREPARE_KERNEL
command, but the musdk-marvell dependency was not prepared up to its
patching step (it was not even extracted at all), causing the
MUSDK_MARVELL_PREPARE_KERNEL hook to fail.

So it seems like adding an entry to the LINUX_EXTENSIONS variable
*after* linux/linux.mk has been processed works fine for the hook
registration, but not for the dependency addition. This looks odd to
me. The generic-package infrastructure does seem to have all the
necessary double-dollars to make sure the evaluation is delayed to the
time of use, but it seems to not be sufficient.

I am missing something obvious here ? I am not sure if I'm seeing
something that's easily fixable, or something that is just plain
impossible due to how make works.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Linux extension from a BR2_EXTERNAL tree

[Arnout Vandecappelle]

On 28/01/2019 17:25, Thomas Petazzoni wrote:
> So it seems like adding an entry to the LINUX_EXTENSIONS variable
> *after* linux/linux.mk has been processed works fine for the hook
> registration, but not for the dependency addition. This looks odd to
> me. The generic-package infrastructure does seem to have all the
> necessary double-dollars to make sure the evaluation is delayed to the
> time of use, but it seems to not be sufficient.
> 
> I am missing something obvious here ? I am not sure if I'm seeing
> something that's easily fixable, or something that is just plain
> impossible due to how make works.

 Yes you're missing something obvious :-)

 inner-generic-package has:

$(1)-depends:           $$($(2)_FINAL_DEPENDENCIES)

 At the time of

$(eval $(generic-package))

in linux.mk, this gets evaluated into

linux-depends:	$(LINUX_FINAL_DEPENDENCIES)

 For dependencies, however, the variable expansion is done then and there. So
with or without $$, this gets immediately expanded into

linux-depends:	<value-of-LINUX_FINAL_DEPENDENCIES-at-the-end-of-linux.mk>

 At that point, linux/linux-ext-*.mk has already been included, so in-tree linux
extensions are fine. However, BR2_EXTERNAL has not yet been included, so that
doesn't work...


 A possible solution that I've been thinking of for quite some time, is to delay
the expansion of inner-generic-package. In fact, it would have to be split into
a generic-package-definitions section, that defines all the rules and
dependencies and so on, and the actual inner-generic-package that just adds the
package name to the list of defined packages. Then, in a second run, we can
expand generic-package-definitions for all defined packages.

 Doing this would e.g. make it possibly to reliable refer to some other
package's _VERSION.

 It might also be useful to reduce empty 'make' time, by limiting the expansion
to only packages that are defined in PACKAGES (and host packages, as long as we
don't have complete Config.in.host).

 The potential breakage is obviously huge :-)


 Regards,
 Arnout

[Buildroot] Linux extension from a BR2_EXTERNAL tree

[Yann E. MORIN]

Thomas, All,

On 2019-01-28 17:25 +0100, Thomas Petazzoni spake thusly:
> I am trying to implement a Linux extension, which applies a bunch of
> patches to the Linux kernel tree, as a package in a BR2_EXTERNAL tree.
[--SNIP--]
> When I build the kernel, it does run the MUSDK_MARVELL_PREPARE_KERNEL
> command, but the musdk-marvell dependency was not prepared up to its
> patching step (it was not even extracted at all), causing the
> MUSDK_MARVELL_PREPARE_KERNEL hook to fail.
> 
> So it seems like adding an entry to the LINUX_EXTENSIONS variable
> *after* linux/linux.mk has been processed works fine for the hook
> registration, but not for the dependency addition. This looks odd to
> me. The generic-package infrastructure does seem to have all the
> necessary double-dollars to make sure the evaluation is delayed to the
> time of use, but it seems to not be sufficient.
> 
> I am missing something obvious here ? I am not sure if I'm seeing
> something that's easily fixable, or something that is just plain
> impossible due to how make works.

It is imposible to do, indeed, because the dependency registration is
expanded by the generic-package infra, see:

    package/pkg-generic.mk at 744:

    $$($(2)_TARGET_CONFIGURE):? | $$($(2)_FINAL_DEPENDENCIES)

So, opnce you have registered the linux package, the line above has
already been evaluated, but your br2-exte5rnal tree has not yet been
parsed, so LINUX_FINAL_DEPENDENCIES does not (yeT) contain the name of
your package.

So, there is no easy way to solve this issue.

Either we scan br2-external before our own packages, or we implement a
mechanism for post-poning the evaluation of packages to after the
br2-external trees have been parsed.

I am fond of neither solution, though, because that would allow
br2-external tree to actuall muck around with existing packages.

In the first case, this could allow a br2-external tree to inject new
dependencies to a package, for example, or to pre-seed variables to
change the way a package's .mk is evaluated, etc...

The second option would allow a br2-external tree to completely override
an exiting package with its very own version, thus breaking a lot of
assumptions made by the system as a whole.

Of course, your use-case is all too valid, but unfortunately, I don't
see a solution... :-(

FTR, I was also thinking of a way for a br2-external tree to provide
pre-built toolchains, or to provide providers of virtual packages that
are a choice (e.g. libjpeg), but in either case it is also very
difficult.to do.

FTR2, I had already implemented my solution 2 (post-pone package
evaluation) in the past, just as a proof-of-concept, but I don't think I
ever posted the patches (but discussing it at the time, the idea was not
very well received anyway, IIRC).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Linux extension from a BR2_EXTERNAL tree

[Ryan Barnett]

Yann and Thomas,

On Mon, Jan 28, 2019 at 11:12 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Thomas, All,
>
> On 2019-01-28 17:25 +0100, Thomas Petazzoni spake thusly:
> > I am trying to implement a Linux extension, which applies a bunch of
> > patches to the Linux kernel tree, as a package in a BR2_EXTERNAL tree.
> [--SNIP--]
> > When I build the kernel, it does run the MUSDK_MARVELL_PREPARE_KERNEL
> > command, but the musdk-marvell dependency was not prepared up to its
> > patching step (it was not even extracted at all), causing the
> > MUSDK_MARVELL_PREPARE_KERNEL hook to fail.
> >
> > So it seems like adding an entry to the LINUX_EXTENSIONS variable
> > *after* linux/linux.mk has been processed works fine for the hook
> > registration, but not for the dependency addition. This looks odd to
> > me. The generic-package infrastructure does seem to have all the
> > necessary double-dollars to make sure the evaluation is delayed to the
> > time of use, but it seems to not be sufficient.
> >
> > I am missing something obvious here ? I am not sure if I'm seeing
> > something that's easily fixable, or something that is just plain
> > impossible due to how make works.
>
> It is imposible to do, indeed, because the dependency registration is
> expanded by the generic-package infra, see:
>
>     package/pkg-generic.mk at 744:
>
>     $$($(2)_TARGET_CONFIGURE):? | $$($(2)_FINAL_DEPENDENCIES)
>
> So, opnce you have registered the linux package, the line above has
> already been evaluated, but your br2-exte5rnal tree has not yet been
> parsed, so LINUX_FINAL_DEPENDENCIES does not (yeT) contain the name of
> your package.
>
> So, there is no easy way to solve this issue.
>
> Either we scan br2-external before our own packages, or we implement a
> mechanism for post-poning the evaluation of packages to after the
> br2-external trees have been parsed.

We've created a "linux-package" type that ties into the linux.mk and
package handling framework. All of the packages that utilize the this
framework are contained with a BR2_EXTERNAL tree. In order to
accomplish this, we had to move the include of linux.mk to after the
BR2_EXTERNAL_MKS. The patch that we carry on our tree is:

diff --git a/Makefile b/Makefile
index a382a5defb..cf6b494a83 100644
--- a/Makefile
+++ b/Makefile
@@ -532,7 +532,6 @@ endif
 include $(sort $(wildcard package/*/*.mk))

 include boot/common.mk
-include linux/linux.mk
 include fs/common.mk

 # If using a br2-external tree, the BR2_EXTERNAL_$(NAME)_PATH variables
@@ -545,6 +544,10 @@ include $(BR2_EXTERNAL_FILE)
 # Nothing to include if no BR2_EXTERNAL tree in use
 include $(BR2_EXTERNAL_MKS)

+# Include after BR2_EXTERNAL tree to allow BR2_EXTERNAL makefile variables
+# to be evalutated in the linux.mk
+include linux/linux.mk
+
 # Now we are sure we have all the packages scanned and defined. We now
 # check for each package in the list of enabled packages, that all its
 # dependencies are indeed enabled.

However, this does have the drawbacks that Yann explained. I haven't
explicitly tested the LINUX_EXTENSIONS framework yet with this but I
believe this modification would work. I'm in the middle of trying to
move our custom "linux-package" (for custom kernel drivers) type to
use the LINUX_EXTENSION framework so I will try to confirm this works
when I get a chance.

[...]

Thanks,
-Ryan

 ---
Ryan Barnett | Sr Systems Engineer | Commercial Avionics
COLLINS AEROSPACE
400 Collins Rd NE, Cedar Rapids, IA 52498 USA
ryan.barnett at collins.com | collinsaerospace.com