openembedded-core.git/meta/classes/module.bbclass, branch morty

module.bbclass: use Module.symvers for dependants

2016-09-08T07:25:18+00:00

When compiling multiple external kernel modules, where one
depends on the other, there are two problems at the
moment:
1) we get compile time warnings from the kernel build
   system due to missing symbols (from modpost).
2) Any modules generated are missing dependency
   information (in the .modinfo elf section) for any
   dependencies outside the current source tree and
   outside the kernel itself.

This is expected, but the kernel build system has a way to
deal with this - the dependent module is expected to
specify KBUILD_EXTRA_SYMBOLS (as a space-separated list)
to point to any and all Module.symvers of kernel modules
that are dependencies.

While 1) by itself is not really a big issue, 2) prevents
the packaging process from generating cross-source tree
package dependencies.

As a first step to solve the missing dependencies in
packages created, we:
1) install Module.symvers of all external kernel module
   builds (into a location that is automatically packaged
   into the -dev package)
2) make use of KBUILD_EXTRA_SYMBOLS and pass the location
   of all Module.symvers of all kernel-module-* packages
   we depend on

This solves both problems mentioned above.

Signed-off-by: André Draszik 
Signed-off-by: Richard Purdie

classes/module: allow substitution of the modules_install target name

2016-03-02T22:39:05+00:00

Quite a few external kernel modules I've found floating around don't
have a modules_install target, but they do have an install target that
basically differs only in name. To make it easier to build these just
make this a MODULES_INSTALL_TARGET variable that you can set from the
recipe - the alternative would be copy-and-paste the do_install
definition from this class which is potentially fragile.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

module/module-base/lttng-modules: Improve kernel module dependencies

2015-05-14T10:41:10+00:00

If we have DEPENDS = "virtual/kernel" is means that the kernel module
depends on the kernel's do_populate_sysroot task. This is not entirely
desireable since that depends on do_install which depends on
do_compile_kernelmodules and so on. In a situation where rm_work in involved
this can cause some pretty length build cycles after the kernel workdir
has been cleaned up by rm_work.

As well as removing this, take the opportunity to clean up duplicated
dependency lines, tweak the dependency of make_scripts for the same
reason and generally try and make things more readable.

Signed-off-by: Richard Purdie

kernel: move source and build output to work-shared

2015-01-16T09:13:02+00:00

commit 3b3f7e785e279 [kernel: Rearrange for 1.8] began the process of
moving the kernel source and build artefacts out of sstate control and
into a shared location.

This changed triggered some workflow issues, as well as bugs related
to the kernel source containing build output, and hence being dirty and
breaking kernel rebuilds.

To solve these issues, and to make it clear that the kernel is not under
sstate control, we move the source and build outputs to:

  work-shared/MACHINE/kernel-source
  work-shared/MACHINE/kernel-build-artifacts

Where kernel-build-artifacts is the kernel build output and
kernel-source is kept "pristine". The build-artifacts contain everything
that is required to build external modules against the kernel source,
and includes the defconfig, the kernel-abiversion, System.map files and
output from "make scripts".

External module builds should either pass O= on the command line, or
set KBUILD_OUTPUT to point to the build-artifacts. module-base.bbclass
takes care of setting KBUILD_OUTPUT, so most existing external module
recipes are transparently adapted to the new source/build layout.

recipes that depend on the kernel source must have a depedency on the
do_shared_workdir task:

 do_configure[depends] += "virtual/kernel:do_shared_workdir"

With this dependency added, the STAGING_KERNEL_DIR will be populated and
available to the rest of the build.

Signed-off-by: Bruce Ashfield 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE

2015-01-16T09:13:01+00:00

When the sstate hash changes for do_configure task, the do_configure
default implementation triggers the 'clean' to be run. For it to
succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
following error:

,----
| DEBUG: Executing shell function do_configure
| NOTE: make -e MAKEFLAGS= clean
| make -C  M=.../tmp/work/... clean
| make[1]: *** M=.../tmp/work/...: No such file or directory.  Stop.
| Makefile:20: recipe for target 'clean' failed
| make: *** [clean] Error 2
| ERROR: oe_runmake failed
`----

Signed-off-by: Otavio Salvador 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

kernel: extract functions for kernel modules to separate bbclass

2013-03-04T10:08:02+00:00

* this way we can reuse the same functionality also for external modules
  including module_autoload_foo and module_conf_foo functionality
* MODULE_PACKAGES variable was removed (splited modules are now returned
  by do_split_packages
* KERNEL_MODULES_META_PACKAGE is used to append all splitted packages
  to RDEPENDS. In kernel.bbclass it's old "kernel-modules" in
  module.bbclass it defaults to ${PN} for upgrade path from
  single PN with all modules to PN depending on all new kernel-module-*

Signed-off-by: Martin Jansa 
Signed-off-by: Richard Purdie

module.bbclass: Create a new depmodwrapper to assist cross-installs

2013-03-01T14:44:33+00:00

Previously the build path to STAGING_KERNEL_DIR was being embedded into the
package post install scripts.  We avoid this behavior by generating a special
depmodwrapper script.  This script contains that hard-coded path, ensuring
that re-use of the sstate-cache (and/or packages) will always run through the
wrapper generated by the current build with a checksum that includes
STAGING_KERNEL_DIR.

[ YOCTO #3962 ]

Signed-off-by: Mark Hatle 
Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie

module.bbclass: Allow for modules to be packaged seperate from ${PN}

2013-02-01T15:51:32+00:00

This patch will allow recipes that provide kernel modules to package
the module or modules in specific packages. That list is contained in
MODULE_PACKAGES, this defaults to  to preserve the current behavior.
The package can also define MODULE_FILES to specify files.

[YOCTO #3803]

(From OE-Core rev: c1ff0467bf03a3342846f0d9dde74e34b740798f)

Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

module.bbclass: Don't add pkg_postinst/pkg_prerm to all packages in recipe

2013-01-29T23:51:59+00:00

The code in module.bbclass was appending the pkg_postinst and
pkg_prerm to all packages that are part of a given recipe, meaning
that the -lic, -dev, -doc, ... packages all got the scriptlet
This change uses  only which macthes with the RDEPENDS and FILES
already used in module.bbclass.

The failure was that rootfs creation would fail due to the -lic package
being installed before the kernel and the script would fail.

[YOCTO #3803]

Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

module.bbclass: do not use update-modules anymore

2013-01-18T13:06:59+00:00

update-modules is obsolete. The bbclass was updated not to use it
anymore.

[YOCTO #3598]

Signed-off-by: Laurentiu Palcu 
Signed-off-by: Richard Purdie