From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 01/11] package-infra: add helper to build kernel modules
Date: Mon, 08 Jun 2015 23:09:39 +0200 [thread overview]
Message-ID: <55760493.1070807@mind.be> (raw)
In-Reply-To: <7f37dfb955f969acf85ea5044c1c4020096d2270.1433628825.git.yann.morin.1998@free.fr>
On 06/07/15 00:20, Yann E. MORIN wrote:
> The Linux kernel offers a nice and easy-to-use infra to build
> out-of-tree kernel modules.
>
> Currently, we have quite a few packages that build kernel modules, and
> most dupliacte (or rewrite) the same code over-and-over again.
duplicate
>
> Introduce a new infrastructure that provides helpers to build kernel
> modules, so packages do not have to duplicate/rewrite that.
>
> The infrastrucutre, unlike any other package infra, is not standalone.
infrastructure
> It needs another package infra to be used. This is so that packages that
> provide both userland and kernel modules can be built easily. So, this
> infra only defines post-build and post-install hooks, that will build
> the kernel modules after the rest of the package.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/Makefile.in | 1 +
> package/pkg-kernel-module.mk | 94 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 95 insertions(+)
> create mode 100644 package/pkg-kernel-module.mk
>
> diff --git a/package/Makefile.in b/package/Makefile.in
> index c02d31f..180fd46 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -398,3 +398,4 @@ include package/pkg-virtual.mk
> include package/pkg-generic.mk
> include package/pkg-kconfig.mk
> include package/pkg-rebar.mk
> +include package/pkg-kernel-module.mk
I think we should at some point put this either in alphabetical or some other
logical order. But for now, it's chaos anyway so OK to just add at the end.
> diff --git a/package/pkg-kernel-module.mk b/package/pkg-kernel-module.mk
> new file mode 100644
> index 0000000..2a2a2cb
> --- /dev/null
> +++ b/package/pkg-kernel-module.mk
> @@ -0,0 +1,94 @@
> +################################################################################
> +# kernel module infrastructure for building Linux kernel modules
> +#
> +# This file implements an frastructure that eases development of package .mk
infrastructure
> +# files for out-of-tree Linux kernel modules. It should be used for all
> +# packages that build a Linux kernel module.
Well, as you say in the cover text, there are a few packages with awkward build
systems that can't use this infra.
> +#
> +# In terms of implementation, this infrastructure requires the .mk file to
> +# only specify metadata information about the package: name, version,
> +# download URL, etc.
I think this is another cut&paste from pkg-generic that is not appropriate.
> +#
> +# It defines post-build and post-install hooks, so that packages can both
> +# build user-space (with any of the other *-package infra) and/or build
> +# kernel modules.
> +#
> +# As such, it is to be used in conjunction with another *-package infra,
> +# like so:
> +#
> +# $(eval $(kernel-module))
> +# $(eval $(generic-package))
> +#
> +# Note: if the caller needs access to the kernel modules (either after they
> +# are built or after they are installed), it will have to define its own
> +# post-build/install hooks after calling kernel-module, but before calling
> +# the other *-package infra, like so:
> +#
> +# $(eval $(kernel-module))
> +# define FOO_MOD_TWEAK
> +# # do something
> +# endef
> +# FOO_POST_BUILD_HOOKS += FOO_MOD_TWEAK
> +# $(eval $(generic-package))
That is not so nice, but I don't see a better alternative.
> +#
> +# Note: this infra does not check that the kernel is enabled; it is expected
> +# to be enforced at the Kconfig level with proper 'depends on'.
> +################################################################################
> +
> +################################################################################
> +# inner-kernel-module -- generates the make targets needed to support building
> +# a kernel module
> +#
> +# argument 1 is the lowercase package name
> +# argument 2 is the uppercase package name, including a HOST_ prefix
> +# for host packages
> +# argument 3 is the uppercase package name, without the HOST_ prefix
> +# for host packages
> +# argument 4 is the type (always 'target')
$(2) is the only one that is used...
> +################################################################################
> +
> +define inner-kernel-module
> +
> +# The kernel must be built first.
> +$(2)_DEPENDENCIES += linux
> +
> +# Duplicate that from pkg-generic because we need it now
> +ifndef $(2)_MAKE
> + $(2)_MAKE = $(MAKE)
> +endif
I don't see why this is needed... The defines below will only be expanded when
the rule is executed (otherwise $(PKG) would not even be defined), so the
definition from pkg-generic is enough, no?
> +
> +ifndef $(2)_MODULE_SUBDIRS
> + $(2)_MODULE_SUBDIRS = .
> +endif
> +
> +# Build the kernel module(s)
> +define $(2)_KERNEL_MODULES_BUILD
> + $$(foreach d,$$($(2)_MODULE_SUBDIRS), \
> + @$$(call MESSAGE,"Building kernel module '$$(d)'")$$(sep) \
I think that "Building kernel module '.'" looks a bit weird... But again, I
can't think of an alternative.
> + $$($$(PKG)_MAKE) -C $$(LINUX_DIR) \
Missing $(LINUX_MAKE_ENV) (or at least TARGET_MAKE_ENV, but I think
LINUX_MAKE_ENV is more appropriate even if it just adds BR_BINARIES_DIR).
> + $$(LINUX_MAKE_FLAGS) \
> + $$($(2)_MODULE_MAKE_OPTS) \
> + M=$$($(2)_DIR)/$$(d) \
We usually use $(@D) instead of $(2)_DIR.
> + modules$$(sep))
> +endef
> +$(2)_POST_BUILD_HOOKS += $(2)_KERNEL_MODULES_BUILD
> +
> +# Install the kernel module(s)
> +define $(2)_KERNEL_MODULES_INSTALL
> + $$(foreach d,$$($(2)_MODULE_SUBDIRS), \
> + @$$(call MESSAGE,"Installing kernel module '$$(d)'")$$(sep) \
> + $$($$(PKG)_MAKE) -C $$(LINUX_DIR) \
> + $$(LINUX_MAKE_FLAGS) \
> + $$($(2)_MODULE_MAKE_OPTS) \
> + M=$$($(2)_DIR)/$$(d) \
> + modules_install$$(sep))
> +endef
> +$(2)_POST_INSTALL_TARGET_HOOKS += $(2)_KERNEL_MODULES_INSTALL
> +
> +endef
> +
> +################################################################################
> +# kernel-module -- the target generator macro for kernel module packages
> +################################################################################
> +
> +kernel-module = $(call inner-kernel-module,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
$(2) is the only one used, so just
kernel-module = $(call inner-kernel-module,$(call UPPERCASE,$(pkgname)))
Regards,
Arnout
>
--
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
next prev parent reply other threads:[~2015-06-08 21:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-06 22:20 [Buildroot] [PATCH 0/11] pkg-kernel-module: new infra to ease building kernel modules (branch yem/kernel-modules) Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 01/11] package-infra: add helper to build kernel modules Yann E. MORIN
2015-06-07 3:22 ` Baruch Siach
2015-06-07 9:59 ` Yann E. MORIN
2015-06-08 12:49 ` rdkehn at yahoo.com
2015-06-08 21:09 ` Arnout Vandecappelle [this message]
2015-06-08 21:25 ` Yann E. MORIN
2015-06-08 21:33 ` Thomas Petazzoni
2015-06-08 21:35 ` Yann E. MORIN
2015-06-08 21:44 ` Yann E. MORIN
2015-06-08 21:52 ` Arnout Vandecappelle
2015-06-08 21:58 ` Yann E. MORIN
2015-06-08 21:59 ` Arnout Vandecappelle
2015-06-06 22:20 ` [Buildroot] [PATCH 02/11] docs/manual: add kernel-module Yann E. MORIN
2015-06-08 21:46 ` Arnout Vandecappelle
2015-06-08 22:02 ` Arnout Vandecappelle
2015-06-08 22:24 ` Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 03/11] package/lttng-modules: use kernel-module helper Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 04/11] package/igh-ethercat: " Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 05/11] package/ktap: " Yann E. MORIN
2015-06-08 21:25 ` Thomas Petazzoni
2015-06-08 21:31 ` Yann E. MORIN
2015-06-08 21:34 ` Yann E. MORIN
2015-06-08 22:11 ` Thomas Petazzoni
2015-06-06 22:20 ` [Buildroot] [PATCH 06/11] package/cryptodev-linux: use the " Yann E. MORIN
2015-06-08 12:33 ` rdkehn at yahoo.com
2015-06-08 17:12 ` Yann E. MORIN
2015-06-08 18:55 ` rdkehn at yahoo.com
2015-06-06 22:20 ` [Buildroot] [PATCH 07/11] package/ocf-linux: use " Yann E. MORIN
2015-06-08 21:35 ` Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 08/11] package/on2-8170-modules: " Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 09/11] package/owl-linux: " Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 10/11] package/simicsfs: " Yann E. MORIN
2015-06-06 22:20 ` [Buildroot] [PATCH 11/11] package/sysdig: " Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55760493.1070807@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.