kernel: consolidated pull request

Hi all,

Here are the latest batch of kernel (and kernel related packages) fixes that I've been working with and testing in my environment.

perf: two commits

[PATCH 4/5] perf: drop PR
[PATCH 5/5] perf: add bash to RDEPENDS

The PR drop is incidental to when I was fixing the bash rdepends issue [YOCTO: #7445], so I kept it in a separate commit.

kernel-tools: two commits

[PATCH 1/5] kern-tools: fix iterative configuration runs [PATCH 2/5] kernel-yocto: split meta data generation from patching phase

These changes were triggered when fixing up QA warnings on the Intel BSPs, and the incremental processing of changing meta data, and re-running the configure and check steps was less than ideal. They are a shuffling and split of the tasks, with no other significant changes.

And finally, a 3.19 -stable kernel update.

[PATCH 3/5] linux-yocto/3.19: integrate korg -stable update

Cheers,

Bruce

The following changes since commit 7f30749fe026e9ceb75d73b89271145a45a60763:

oeqa/parselogs: Skip hda opcode errors (2015-03-12 12:50:24 +0000)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib zedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (5):
kern-tools: fix iterative configuration runs
kernel-yocto: split meta data generation from patching phase linux-yocto/3.19: integrate korg -stable update
perf: drop PR
perf: add bash to RDEPENDS

 meta/classes/kernel-yocto.bbclass                    |  9 +++++++--
 .../kern-tools/kern-tools-native_git.bb              |  2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.19.bb        | 20 ++++++++++----------
 meta/recipes-kernel/perf/perf.bb                     |  4 +---
 5 files changed, 22 insertions(+), 19 deletions(-)

2.1.0

When fixing a kernel configuration warning, it is often necessary to modify the kernel's meta-data and re-run the tools to update and re-audit the config. This implies that the patch, config and audit steps are run multiple times.

The tools had a bug that would incorrectly restore old meta-data versus using updated configuration. Updating the kern-tools SRCREV to fix the issue.

---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 131c5e9d0e2b..a1ec198fde7f 100644
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
 
 DEPENDS = "git-native"
 
-SRCREV = "0c51a3d02fa54726141f32824b11d0676960e0a5"
+SRCREV = "83e5493ea46067152609008ade131971eaebbb27"
 PR = "r12"
 PV = "0.2+git${SRCPV}"
 

2.1.0

The linux-yocto kernel has a meta-data component which accompanies the actual tree. That meta-data is processed to generate a series file that controls the patching and configuration of the kernel.

patching and configuration are two distinct phases, so when working on kernel configuration, it doesn't make sense to always have to re-run the patching step just to update configuration data in the meta-series.

To allow a more granular set of tasks, we break the meta-data generation into a separate task, which runs before do_patch. This allows the task to be explicitly called when working on configuration, but otherwise has no impact on the build.

---
 meta/classes/kernel-yocto.bbclass | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

index 8db489964ed2..1e226a5722ac 100644
@@ -55,7 +55,7 @@ def get_machine_branch(d, default):
 	    
     return default
 
-do_patch() {
+do_kernel_metadata() {
 	cd ${S}
 	export KMETA=${KMETA}
 

@@ -81,7 +81,7 @@ do_patch() {
 		createme_flags="--disable-meta-gen --meta ${KMETA}"
 	fi
 
-	createme ${createme_flags} ${ARCH} ${machine_branch}
+	createme -v -v ${createme_flags} ${ARCH} ${machine_branch}
 	if [ $? -ne 0 ]; then
 		bbfatal "Could not create ${machine_branch}"
 	fi

@@ -118,6 +118,10 @@ do_patch() {
 	if [ $? -ne 0 ]; then
 		bbfatal "Could not update ${machine_branch}"
 	fi
+}
+
+do_patch() {
+	cd ${S}
 
 	# executes and modifies the source tree as required
 	patchme ${KMACHINE}

@@ -221,6 +225,7 @@ do_kernel_checkout() {
 do_kernel_checkout[dirs] = "${S}"
 
 addtask kernel_checkout before do_patch after do_unpack
+addtask kernel_metadata after do_validate_branches before do_patch
 
 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {

2.1.0

It was. The extra output only goes to the logs, and it is helpful in diagnosing problems.

.. and yes, the obvious follow up is that I should have put that in the commit message!

Bruce

It looked a bit like debugging changes, thought I'd check.

Cheers,
Ross

Always better to be safe. It's not like we all haven't left those in before :)

Bruce

I'm still trying to repend for not noticing that Randy's patch called a test suite "test_foo". :)

Ross

Updating to the latest and greatest -stable release for the 3.19 series.

---
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.19.bb      | 20 ++++++++++----------
 2 files changed, 13 insertions(+), 13 deletions(-)

index d10449aab365..98ffc5a3cc37 100644
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "3.19"
+LINUX_VERSION ?= "3.19.1"
 
 KMETA = "meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "43b9eced9ba8a57add36af07736344dcc383f711"
-SRCREV_meta ?= "f7a81274b461d0c748964d75c24bea8574d350fb"
+SRCREV_machine ?= "8c38c1015bbb5fc121018f67ed45a7eb2f357cfe"
+SRCREV_meta ?= "e3303ca4bd7d7a5a3d9a9a9a9467c4c70db4258d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 

index f1bf3bea9016..31321c55e984 100644
@@ -11,19 +11,19 @@ KBRANCH_qemux86  ?= "standard/common-pc"
 KBRANCH_qemux86-64 ?= "standard/common-pc-64/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "91b64df8cdcdacb9ef8d707a0c34f55a09bf170d"
-SRCREV_machine_qemuarm64 ?= "43b9eced9ba8a57add36af07736344dcc383f711"
-SRCREV_machine_qemumips ?= "7c67469a4c77a977c46f218de7e2f4699292d28b"
-SRCREV_machine_qemuppc ?= "7dc29d4265b44ad28ea3ec950b1a86be08933ce8"
-SRCREV_machine_qemux86 ?= "43b9eced9ba8a57add36af07736344dcc383f711"
-SRCREV_machine_qemux86-64 ?= "43b9eced9ba8a57add36af07736344dcc383f711"
-SRCREV_machine_qemumips64 ?= "b7ab9d4bac55415f125c81f529dbbefb07de98ad"
-SRCREV_machine ?= "43b9eced9ba8a57add36af07736344dcc383f711"
-SRCREV_meta ?= "f7a81274b461d0c748964d75c24bea8574d350fb"
+SRCREV_machine_qemuarm ?= "a40304a6dfdad6618420854121ee91cf09481bd4"
+SRCREV_machine_qemuarm64 ?= "8c38c1015bbb5fc121018f67ed45a7eb2f357cfe"
+SRCREV_machine_qemumips ?= "6f1c5213591d7a35efc542a0971c70dcd16ea00e"
+SRCREV_machine_qemuppc ?= "6b9a1cb9e10e76d8a3102c046656c93651fde9ab"
+SRCREV_machine_qemux86 ?= "8c38c1015bbb5fc121018f67ed45a7eb2f357cfe"
+SRCREV_machine_qemux86-64 ?= "8c38c1015bbb5fc121018f67ed45a7eb2f357cfe"
+SRCREV_machine_qemumips64 ?= "723d6e1eb8dfa06f374d925d2c36e22feb1a2c86"
+SRCREV_machine ?= "8c38c1015bbb5fc121018f67ed45a7eb2f357cfe"
+SRCREV_meta ?= "e3303ca4bd7d7a5a3d9a9a9a9467c4c70db4258d"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
 
-LINUX_VERSION ?= "3.19"
+LINUX_VERSION ?= "3.19.1"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 

2.1.0

We no longer need an explicit PR, so we can safely drop it from the perf recipe.

---
 meta/recipes-kernel/perf/perf.bb | 2 --
 1 file changed, 2 deletions(-)

index f69d177949e5..4f820f1c88a3 100644
@@ -9,8 +9,6 @@ as well."
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
-PR = "r9"
-
 require perf-features.inc
 
 BUILDPERF_libc-uclibc = "no"

2.1.0

In general you can only remove PR if it's r0 (as that's the default in bitbake.conf), so this will have to remain until the PV for perf is changed. But perf is versioned according to the kernel that it's built against so I think this PR is destined to stay forever as perf has no control over it's own version.

Ross

cool. That's fine with me, I honestly didn't know the rules, and that's why i kept it separate!

But doesn't that mean that my bash RDEPENDS fix needs a PR bump ?

Bruce

No, you don't need to bump as the PR service will bump when it rebuilds.

Ross

Great. So you'll just drop my PR patch, and the keep the other. Just making sure that I don't need a resend, since I'm heading for a flight and won't be around for the next 6 or 7 hours :)

Bruce

Yeah don't bother re-sending, I dropped that patch and merged the rest.

Ross

perf has a dependency on bash in its utilities, which generate the following warning:

WARNING: QA Issue: perf requires /bin/bash, but no providers in its RDEPENDS [file-rdeps]

Since perf is not installed on extremely small systems, we just add bash to the RDEPENDS, rather than modifying scripts or removing content.

[YOCTO: #7445]

---
 meta/recipes-kernel/perf/perf.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 4f820f1c88a3..a909132beb86 100644
@@ -168,7 +168,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl ${PN}-python"
 
-RDEPENDS_${PN} += "elfutils"
+RDEPENDS_${PN} += "elfutils bash"
 RDEPENDS_${PN}-archive =+ "bash"
 RDEPENDS_${PN}-python =+ "bash python"
 RDEPENDS_${PN}-perl =+ "bash perl perl-modules"

2.1.0