| Age | Commit message (Collapse) | Author | Files |
|---|
|
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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 <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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 <richard.purdie@linuxfoundation.org>
|
|
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 <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* 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 <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <mark.hatle@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
update-modules is obsolete. The bbclass was updated not to use it
anymore.
[YOCTO #3598]
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If do_make_scripts() executes before do_unpack()/do_patch(), the build
fails because it can't cd into the workdir of a recipe using this
class, so make sure do_make_scripts() doesn't run before the package
has been unpacked and patched.
Fixes [YOCTO #3589].
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It's sometimes useful to have this function available to recipes which
don't wish to use module.bbclass for whatever reason.
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
The update-modules mechanism is something of a historical relic and it isn't
entirely clear that it has a great deal of value nowadays. Also, it causes a
problem when building a read-only rootfs since update-modules itself refuses
to configure offline.
Allow DISTROs to circumvent this whole thing by declaring (via DISTRO_FEATURES)
that they don't wish to use update-modules. This is backfilled for existing
distributions and will have to be marked as CONSIDERED by those who actually
don't want it.
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
* depmod already gets executed by pkg_postinst_kernel-image.
* If you build a module using module.bbclass, pkg_postinst returns 1 in
do_rootfs, causing pkg_postinst to run again on first boot. To improve
this situation, I copied pkg_postinst from kernel.bbclass to module.bbclass.
This was rejected by Koen, because he doesn't like the code from
kernel.bblcass, which uses ${STAGING_DIR_KERNEL}. Richard then suggested
that calling depmod during do_rootfs wasn't necessary at all, because
it already gets done by kernel-image.
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When external modules are built, files in $STAGING_KERNEL_DIR/scripts/basic will/can get
rebuilt.
This raises a potential race condition. Prevent this by adding a lock around the
do_make_scripts() function. Further, make sure that the kernel has been installed
to the sysroot, prior to executing this new task.
Signed-off-by: Anders Darander <anders@chargestorm.se>
|
|
out-of-tree modules
The existing infrastructure uses an external build tree which references the
kernel source in the work dir. If run with rm work, building external modules
will fail.
This patch places a configured source tree in sysroots. Striking a balance
between minimal size and minimal maintenance is difficult. A fully configured
tree is about 500MB after a clean. This version leans on the side of caution and
removes only the obviously unecessary parts of the source tree to conserve
space, resulting in about 170MB. The arch directories would be some additional
pruning we could do. Given examples from the devel package from distributions, I
suspect this size could be reduced to 75MB or so, but at the cost of a much more
complex recipe which is likely to require a great deal more maintenance to keep
current with kernel releases.
Care is also taken to clean the hostprogs in scripts, and the modules are
responsible for building them as needed. Although it is unclear to me if this is
really necessary, especially considering that modules put these bits back as
soon as they compile. If we are not generating an sstate package, I suspect we
can ignore these.
Please try this with your modules and let me know how it does. I tried to take
non linux-yocto kernel recipes into account, but I have only tested with
linux-yocto and the hello-mod recipe so far.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Acked-by: Koen Kooi <koen@dominion.thruhere.net>
Acked-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This fixes [BUGID #241]
The kernel hostprogs are built for the host architecture. They should not be
deployed to the target, and they should not be included in an sstate package
which might get reused on a host of a different architecture.
As we don't build many out-of-tree modules, this patch takes the approach of
building the hostprogs as part of the module compile process with a
do_compile_prepend() routine in module.bbclass.
We don't have to clean the hostprogs as modules depend on the kernel being
populate_staging, so its done with the staging directory by the time we run.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Gary Thomas <gary@mlbassoc.com>
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@4518 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@3422 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@2639 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@1925 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@651 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
|
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@530 311d38ba-8fff-0310-9ca6-ca027cbcb966
|
