[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[robert.mccabe at rockwellcollins.com]

From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>

Allows external projects to inject custom code inside the Linux source
tree.

Although a simple change that *shouldn't* be controversial I'm troubled
by the comment a few lines above:

   #However, since the files we include here are in the same directory as
   #the current Makefile, we are OK. But this is a hard requirement: files
   #included here *must* be in the same directory!

I'm not seeing why this is a "hard requirement" ...

Signed-off-by: McCabe, Robert J <robert.mccabe@rockwellcollins.com>
---
 linux/linux.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/linux/linux.mk b/linux/linux.mk
index 2b5d096e14..af3de401d1 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -514,6 +514,12 @@ endef
 # included here *must* be in the same directory!
 include $(sort $(wildcard linux/linux-ext-*.mk))

+define INCLUDE_EXTERNAL_LINUX_EXTENSIONS
+-include $(sort $(wildcard $(1)/linux/linux-ext-*.mk))
+endef
+$(foreach ext,$(BR2_EXTERNAL_DIRS), \
+       $(eval $(call INCLUDE_EXTERNAL_LINUX_EXTENSIONS,$(ext))))
+
 LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\
        $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext)))

--
2.17.1

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Matthew Weber]

Hi Rob,

On Mon, Jul 8, 2019 at 7:58 PM <robert.mccabe@rockwellcollins.com> wrote:
>
> From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>
>
> Allows external projects to inject custom code inside the Linux source
> tree.
>
> Although a simple change that *shouldn't* be controversial I'm troubled
> by the comment a few lines above:
>
>    #However, since the files we include here are in the same directory as
>    #the current Makefile, we are OK. But this is a hard requirement: files
>    #included here *must* be in the same directory!
>
> I'm not seeing why this is a "hard requirement" ...

There was some discussion on a similar thread earlier this year. (I
added Ryan Barnett as we had similar interest in converting our
internal linux extension over to the upstream approach.)
http://buildroot-busybox.2317881.n4.nabble.com/Linux-extension-from-a-BR2-EXTERNAL-tree-td214834.html#a214845


>
> Signed-off-by: McCabe, Robert J <robert.mccabe@rockwellcollins.com>
> ---
>  linux/linux.mk | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 2b5d096e14..af3de401d1 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -514,6 +514,12 @@ endef
>  # included here *must* be in the same directory!
>  include $(sort $(wildcard linux/linux-ext-*.mk))
>
> +define INCLUDE_EXTERNAL_LINUX_EXTENSIONS
> +-include $(sort $(wildcard $(1)/linux/linux-ext-*.mk))
> +endef
> +$(foreach ext,$(BR2_EXTERNAL_DIRS), \
> +       $(eval $(call INCLUDE_EXTERNAL_LINUX_EXTENSIONS,$(ext))))
> +
>  LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\
>         $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext)))
>
> --
> 2.17.1
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 

Matthew Weber | Pr. Software Engineer | Commercial Avionics

COLLINS AEROSPACE

400 Collins Road NE, Cedar Rapids, Iowa 52498, USA

Tel: +1 319 295 7349 | FAX: +1 319 263 6099

matthew.weber at collins.com | collinsaerospace.com



CONFIDENTIALITY WARNING: This message may contain proprietary and/or
privileged information of Collins Aerospace and its affiliated
companies. If you are not the intended recipient, please 1) Do not
disclose, copy, distribute or use this message or its contents. 2)
Advise the sender by return email. 3) Delete all copies (including all
attachments) from your computer. Your cooperation is greatly
appreciated.


Any export restricted material should be shared using my
matthew.weber at corp.rockwellcollins.com address.

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Arnout Vandecappelle]

On 09/07/2019 04:15, Matthew Weber wrote:
> Hi Rob,
> 
> On Mon, Jul 8, 2019 at 7:58 PM <robert.mccabe@rockwellcollins.com> wrote:
>>
>> From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>
>>
>> Allows external projects to inject custom code inside the Linux source
>> tree.
>>
>> Although a simple change that *shouldn't* be controversial I'm troubled
>> by the comment a few lines above:
>>
>>    #However, since the files we include here are in the same directory as
>>    #the current Makefile, we are OK. But this is a hard requirement: files
>>    #included here *must* be in the same directory!
>>
>> I'm not seeing why this is a "hard requirement" ...
> 
> There was some discussion on a similar thread earlier this year. (I
> added Ryan Barnett as we had similar interest in converting our
> internal linux extension over to the upstream approach.)
> http://buildroot-busybox.2317881.n4.nabble.com/Linux-extension-from-a-BR2-EXTERNAL-tree-td214834.html#a214845

 Thomas's approach in that thread, however, was to include the extension *after*
linux.mk expansion. This doesn't work, as explained in that thread.


 Regards,
 Arnout

[snip]

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Arnout Vandecappelle]

On 09/07/2019 04:15, Matthew Weber wrote:
> Hi Rob,
> 
> On Mon, Jul 8, 2019 at 7:58 PM <robert.mccabe@rockwellcollins.com> wrote:
>>
>> From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>
>>
>> Allows external projects to inject custom code inside the Linux source
>> tree.
>>
>> Although a simple change that *shouldn't* be controversial I'm troubled
>> by the comment a few lines above:
>>
>>    #However, since the files we include here are in the same directory as
>>    #the current Makefile, we are OK. But this is a hard requirement: files
>>    #included here *must* be in the same directory!
>>
>> I'm not seeing why this is a "hard requirement" ...
> 
> There was some discussion on a similar thread earlier this year. (I
> added Ryan Barnett as we had similar interest in converting our
> internal linux extension over to the upstream approach.)
> http://buildroot-busybox.2317881.n4.nabble.com/Linux-extension-from-a-BR2-EXTERNAL-tree-td214834.html#a214845

 Thomas's approach in that thread, however, was to include the extension *after*
linux.mk expansion. This doesn't work, as explained in that thread.


 Regards,
 Arnout

[snip]

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Arnout Vandecappelle]

On 09/07/2019 02:58, robert.mccabe at rockwellcollins.com wrote:
> From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>
> 
> Allows external projects to inject custom code inside the Linux source
> tree.
> 
> Although a simple change that *shouldn't* be controversial I'm troubled
> by the comment a few lines above:
> 
>    #However, since the files we include here are in the same directory as
>    #the current Makefile, we are OK. But this is a hard requirement: files
>    #included here *must* be in the same directory!
> 
> I'm not seeing why this is a "hard requirement" ...

 It's explained above: to identify the package name, the generic-package macro
uses the directory of the last entry in MAKEFILE_LIST. MAKEFILE_LIST contains
the list of all files included up to that point. So, by including extra files
from within linux.mk, the package name (which should be 'linux') will be set to
the directory in which the last included file resides...

> 
> Signed-off-by: McCabe, Robert J <robert.mccabe@rockwellcollins.com>
> ---
>  linux/linux.mk | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 2b5d096e14..af3de401d1 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -514,6 +514,12 @@ endef
>  # included here *must* be in the same directory!
>  include $(sort $(wildcard linux/linux-ext-*.mk))
> 
> +define INCLUDE_EXTERNAL_LINUX_EXTENSIONS
> +-include $(sort $(wildcard $(1)/linux/linux-ext-*.mk))

 ... However, here you make sure that the directory is *still* called 'linux',
so all is well.

> +endef
> +$(foreach ext,$(BR2_EXTERNAL_DIRS), \
> +       $(eval $(call INCLUDE_EXTERNAL_LINUX_EXTENSIONS,$(ext))))

 I don't really like this eval construct very much. I think it's cleaner to do

-include $(sort $(wildcard $(foreach ext,$(BR2_EXTERNAL_DIRS), \
	$(ext)/linux/linux-ext-*.mk)))

[as always, untested.]

 Regards,
 Arnout

> +
>  LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\
>         $(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext)))
> 
> --
> 2.17.1
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Arnout Vandecappelle]

On 09/07/2019 02:58, robert.mccabe at rockwellcollins.com wrote:
> From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>

 By the way, isn't the company called Collins Aerospace now, with collins.com as
e-mail domain?

 Regards,
 Arnout

[Buildroot] [RFC] BR2_EXTERNAL linux-kernel-extensions support

[Matthew Weber]

On Tue, Jul 9, 2019 at 12:24 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 09/07/2019 02:58, robert.mccabe at rockwellcollins.com wrote:
> > From: "McCabe, Robert J" <robert.mccabe@rockwellcollins.com>
>
>  By the way, isn't the company called Collins Aerospace now, with collins.com as
> e-mail domain?

We wish but the email with collins.com goes through a
scrubber/authentication stuff and doesn't work with mailing lists.....

>
>  Regards,
>  Arnout
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 

Matthew Weber | Pr. Software Engineer | Commercial Avionics

COLLINS AEROSPACE

400 Collins Road NE, Cedar Rapids, Iowa 52498, USA

Tel: +1 319 295 7349 | FAX: +1 319 263 6099

matthew.weber at collins.com | collinsaerospace.com



CONFIDENTIALITY WARNING: This message may contain proprietary and/or
privileged information of Collins Aerospace and its affiliated
companies. If you are not the intended recipient, please 1) Do not
disclose, copy, distribute or use this message or its contents. 2)
Advise the sender by return email. 3) Delete all copies (including all
attachments) from your computer. Your cooperation is greatly
appreciated.


Any export restricted material should be shared using my
matthew.weber at corp.rockwellcollins.com address.