linux-yocto: kernel config updates

Richard/Saul,

Here's another small series of kernel config updates from the linux-yocto tree. During some build/boot and regression testing I noticed that some configuration warnings weren't being dumped to a visible location. When I moved all the warnings (patch 3/3) to the kernel audit phase, there were some obvious clenaups to the configs to get us a clean audit.

I've built and booted all the qemu machine. The net result here is that we don't have any runtime config changes and we have met the clean kernel configuration goal.

The following changes since commit bcfff457f63f43f53bcaf04f116e09bb2bba9bd6:

Fix mercurial fetcher in fetch2 (2011-09-21 14:07:31 +0100)

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 (3):
linux-yocto: simplify kernel configuration check expression
linux-yocto: add blktrace feature
linux-yocto: kernel configuration cleanups

 meta/classes/kernel-yocto.bbclass                  |    2 +-
 .../kern-tools/kern-tools-native_git.bb            |    2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb    |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.0.bb       |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

1.7.4.1

kernel configuration validation takes place between two files. An unprocessed configuration file (which is all the options found in the various configuration fragments) and the final .config produced by the lkc.

The unprocessed configuration file's name historically is based on the name of the branch that was used to build the BSP. But with the ability to map machine names to arbitrary branches, this is no longer always true.

Searching for the pattern *-config-* in the meta subdirectory will only match the config file, and frees the config validation phase from being concerned with what branch was used to build the BSP.

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

index 0f92267..2205686 100644
@@ -105,7 +105,7 @@ python do_kernel_configcheck() {
     bb.plain("NOTE: validating kernel configuration")
 
     pathprefix = "export PATH=%s; " % bb.data.getVar('PATH', d, True)
-    cmd = bb.data.expand("cd ${B}/..; kconf_check -${LINUX_KERNEL_TYPE}-config- ${B} ${S} ${B} ${KBRANCH}",d )
+    cmd = bb.data.expand("cd ${B}/..; kconf_check -config- ${B} ${S} ${B} ${KBRANCH}",d )
     ret, result = commands.getstatusoutput("%s%s" % (pathprefix, cmd))
 
     bb.plain( "%s" % result )

1.7.4.1

Updating the 3.0 kernel to enable blktrace to match our previous functionality. This is done by the following meta branch commit:

[
meta: add blktrace feature

Add a 'blktrace feature' that turns on kernel support for blktrace, a block I/O tracing tool. Added to 'standard' alongside similar tracing tool config.

]

---
 meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.0.bb    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

index b3bb4ac..eb329c5 100644
@@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE = "preempt-rt"
 
 SRCREV_machine ?= "0936e13cc65d816f1759e2322c5e3fc82a5037f3"
 SRCREV_machine_qemuppc ?= "0936e13cc65d816f1759e2322c5e3fc82a5037f3"
-SRCREV_meta ?= "12574e5a77597f6938315ef82d18fc5e229fb79c"
+SRCREV_meta ?= "334b8479297954d94c97f81164e3363ed7ae70e5"
 
 PR = "r1"
 PV = "${LINUX_VERSION}+git${SRCPV}"

index 4b1bdb2..0160966 100644
@@ -18,7 +18,7 @@ SRCREV_machine_qemuppc ?= "eccd57eaa4c2b580b9adbbc39e19ecbff56779ae"
 SRCREV_machine_qemux86 ?= "72671808fdbe69a9fe03fd8f094e7c59da04a28c"
 SRCREV_machine_qemux86-64 ?= "2b2d0954a6fd12b4bb7f02f019bc62633c8060a1"
 SRCREV_machine ?= "6b2c7d65b844e686eae7d5cccb9b638887afe28e"
-SRCREV_meta ?= "12574e5a77597f6938315ef82d18fc5e229fb79c"
+SRCREV_meta ?= "334b8479297954d94c97f81164e3363ed7ae70e5"
 
 PR = "r2"
 PV = "${LINUX_VERSION}+git${SRCPV}"

1.7.4.1

There were some config fragment warnings that were being hidden by virtue of being output while generating the full config versus the ones that were generated during the configuration audit task.

This change does the following:

- Updates the kern-tools SRCREV to include changes that move all kernel configuration warnings to the audit script

- Updates the meta SRCREV for linux-yocto to get updated kernel configuration fragments that are warning-free. These are duplicated configs, and other changes that have a net result of no runtime changes.

---
 .../kern-tools/kern-tools-native_git.bb            |    2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb    |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.0.bb       |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

index edaaea6..87aa574 100644
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
 
 DEPENDS = "git-native guilt-native"
 
-SRCREV = "60723c84395a9ac1753589824e30be39a781bb82"
+SRCREV = "364437739c45a5e771d1f7b3ac73c35f1328fd97"
 PR = r10
 PV = "0.1+git${SRCPV}"
 

index eb329c5..2b7a4f9 100644
@@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE = "preempt-rt"
 
 SRCREV_machine ?= "0936e13cc65d816f1759e2322c5e3fc82a5037f3"
 SRCREV_machine_qemuppc ?= "0936e13cc65d816f1759e2322c5e3fc82a5037f3"
-SRCREV_meta ?= "334b8479297954d94c97f81164e3363ed7ae70e5"
+SRCREV_meta ?= "0dcdf7bb40a8e1fb18fd27d442fa5ace8cff4941"
 
 PR = "r1"
 PV = "${LINUX_VERSION}+git${SRCPV}"

index 0160966..f11c0ea 100644
@@ -18,7 +18,7 @@ SRCREV_machine_qemuppc ?= "eccd57eaa4c2b580b9adbbc39e19ecbff56779ae"
 SRCREV_machine_qemux86 ?= "72671808fdbe69a9fe03fd8f094e7c59da04a28c"
 SRCREV_machine_qemux86-64 ?= "2b2d0954a6fd12b4bb7f02f019bc62633c8060a1"
 SRCREV_machine ?= "6b2c7d65b844e686eae7d5cccb9b638887afe28e"
-SRCREV_meta ?= "334b8479297954d94c97f81164e3363ed7ae70e5"
+SRCREV_meta ?= "0dcdf7bb40a8e1fb18fd27d442fa5ace8cff4941"
 
 PR = "r2"
 PV = "${LINUX_VERSION}+git${SRCPV}"

1.7.4.1

Merged to master. I'm a little worried we're still finding issues like this at this late stage :/.

Cheers,

Richard

Just housekeeping. They've been there for a while, and with the bigger rocks to move I hadn't realized that the mapping to the kern-tools was hiding output. We could have waited, but since the impact was nil on the end result, I figured it was worth putting a good face forward for 1.1!

Cheers,

Bruce