[PATCH 0/8] linux-yocto + kern tools consolidated pull request

[PATCH 0/8] linux-yocto + kern tools consolidated pull request

[Bruce Ashfield]

Richard/Saul,

This is a collection of updates that I've had locally in the last few
weeks leading up to the 1.3 release, but they were held back to avoid
any negative impacts on the release.

I've kept all the kernel -stable and configuration updates as distinct
commits, so it will be possible to separate any issues that crop up 
into manageable chunks. It also shows the different test points that 
I've used while updating the kernels.

For the kernel trees we get the following:

  - the latest 3.2 and 3.4 -stable updates
  - the latest 3.2 and 3.4 -rt updates
  - configuration changes that have been collected for BSPs

  ** As far as I'm concerned these are all bugfix/stable changes and
     can go into danny-next. Others may not agree :)

These have been build tested to the amount that my cycles allow, and
others have already been used in the meta-intel BSPs. It's worth running
this through a test build if you are so inclined, just to be sure.

For the tools we get the following updates:

  - A fix for YOCTO #3226 that silences the warning:

       find: warning: -path $oe-path/linux/ will not match anything because it ends with /.

    ** This change should be considering for the danny-next branch as well.

  - A fix to the guilt SRC_URI to point at a valid tgz upstream.

    ** This change should be considering for the danny-next branch as well.

  - kern-tools improvements and fixes that are part of the 1.4 feature work.
    The kern-tools commit has the details of the changes. They'll be further
    improved in the upcoming weeks, but they have been in use locally for 
    over a month now, and have been tested by others as well, so they shouldn't
    cause any problems in master and are invisible to most users.

I've added Ross to the CC for the commits that can be pulled into the 1.3
maintenance branches.

I've added Rahul since there was some refactoring of the Rangely/dpdk
configuration that should be checked as well.

Cheers,

Bruce  

The following changes since commit 41125ddc8651494ffcf888d3b5efce1ae6d953bb:

  bitbake: print clear message for "bitbake -e ASSUME_PROVIDED" (2012-11-13 14:21:16 +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 (8):
  linux-yocto/3.4: nfsd, pci, fishriver and rangely config changes
  linux-yocto/3.4: efi/mmc fixes and fri2 updates
  linux-yocto/3.4: bump kver to v3.4.16
  linux-yocto/3.4: v3.4.17, v3.4.18, -rt and config changes
  linux-yocto/3.2: update to v3.2.32 and 3.2.32-rt48
  kern-tools: kconf_check: fix find warning
  kern-tools: flexibility and usability enhancements
  guilt: change upstream tgz location

 meta/recipes-devtools/guilt/guilt-native_0.33.bb     |    4 ++--
 .../kern-tools/kern-tools-native_git.bb              |    2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb      |    8 ++++----
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb      |    8 ++++----
 meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb    |    6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb    |    7 +++----
 meta/recipes-kernel/linux/linux-yocto_3.2.bb         |   18 +++++++++---------
 meta/recipes-kernel/linux/linux-yocto_3.4.bb         |   16 ++++++++--------
 8 files changed, 34 insertions(+), 35 deletions(-)

-- 
1.7.10.4

[PATCH 1/8] linux-yocto/3.4: nfsd, pci, fishriver and rangely config changes

[Bruce Ashfield]

Updating the 3.4 meta branch with the following configuration changes
and additions:

0541ba5 meta: Rangeley Machine Created
9e3bdb7 meta: Add nfsd kernel features
da9b37d CrystalForest: Enable PCI extended config space for CrystalForest Machine.
628cbe9 meta: Add a new feature for PCI devices.
9c3a2b3 meta: fishriver: remove meta-data

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb   |    2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.4.bb      |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 91dc54f..bbac322 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = "meta"
 
 SRCREV_machine ?= "5705c8037d2c47938034ead87c70ae3ebef552f7"
 SRCREV_machine_qemuppc ?= "c8b651aab5d2d5c0839cdedc0c0ec5dc09cf47c0"
-SRCREV_meta ?= "a201268353c030d9fafe00f2041976f7437d9386"
+SRCREV_meta ?= "0541ba5f98f31419e9bdfec895c18029bf424e7c"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
index 60b877f..e1d349d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
@@ -13,7 +13,7 @@ LINUX_VERSION ?= "3.4.11"
 KMETA = "meta"
 
 SRCREV_machine ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-SRCREV_meta ?= "a201268353c030d9fafe00f2041976f7437d9386"
+SRCREV_meta ?= "0541ba5f98f31419e9bdfec895c18029bf424e7c"
 
 
 PR = "${INC_PR}.0"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 3383147..904e79e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -9,7 +9,7 @@ SRCREV_machine_qemuppc ?= "7833f1549c3d44cce8aea38b65cd501229aad492"
 SRCREV_machine_qemux86 ?= "449f7f520350700858f21a5554b81cc8ad23267d"
 SRCREV_machine_qemux86-64 ?= "449f7f520350700858f21a5554b81cc8ad23267d"
 SRCREV_machine ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-SRCREV_meta ?= "a201268353c030d9fafe00f2041976f7437d9386"
+SRCREV_meta ?= "0541ba5f98f31419e9bdfec895c18029bf424e7c"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
-- 
1.7.10.4

[PATCH 2/8] linux-yocto/3.4: efi/mmc fixes and fri2 updates

[Bruce Ashfield]

Updating the 3.4 SRCREVs to pick up the following two fixes:

 218bd8d efi: Add patch to fix 32bit EFI service mapping (rhbz 726701)
 b6d08f7 mmc: sdhci: Use DBG() instead of pr_warning() on large timeout

And the following meta branch config updates:

 68a635b fri2: Disable GPIO_PCH for preempt-rt
 2ec32d5 fri2: Add fri2-tiny support
 a7b9607 fri2: Required boot config for fri2
 bed2080 fri2: Remove graphics options from the core fri2 description

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb   |    6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb |    5 ++---
 meta/recipes-kernel/linux/linux-yocto_3.4.bb      |   14 +++++++-------
 3 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index bbac322..bdbecf4 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -8,9 +8,9 @@ LINUX_KERNEL_TYPE = "preempt-rt"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "5705c8037d2c47938034ead87c70ae3ebef552f7"
-SRCREV_machine_qemuppc ?= "c8b651aab5d2d5c0839cdedc0c0ec5dc09cf47c0"
-SRCREV_meta ?= "0541ba5f98f31419e9bdfec895c18029bf424e7c"
+SRCREV_machine ?= "fb596148058bf5e7ef550a040d143bdfbf4146b0"
+SRCREV_machine_qemuppc ?= "b24ede45575d58ace08633f0e8fd31b594c5c80e"
+SRCREV_meta ?= "68a635bf8dfb64b02263c1ac80c948647cc76d5f"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
index e1d349d..772cfef 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
@@ -12,9 +12,8 @@ LINUX_VERSION ?= "3.4.11"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-SRCREV_meta ?= "0541ba5f98f31419e9bdfec895c18029bf424e7c"
-
+SRCREV_machine ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
+SRCREV_meta ?= "68a635bf8dfb64b02263c1ac80c948647cc76d5f"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 904e79e..22593c6 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,13 +3,13 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH_DEFAULT = "standard/base"
 KBRANCH = "${KBRANCH_DEFAULT}"
 
-SRCREV_machine_qemuarm ?= "8ee53c3b82ada3cdfd7d25f07d3975834ac9a9b2"
-SRCREV_machine_qemumips  ?= "caf99a20e3c3ba036ed1bb46875059a0d24e4fbd"
-SRCREV_machine_qemuppc ?= "7833f1549c3d44cce8aea38b65cd501229aad492"
-SRCREV_machine_qemux86 ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-SRCREV_machine_qemux86-64 ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-SRCREV_machine ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-SRCREV_meta ?= "0541ba5f98f31419e9bdfec895c18029bf424e7c"
+SRCREV_machine_qemuarm ?= "cec289be595a5889740ad4f0a58d12579f528d5e"
+SRCREV_machine_qemumips  ?= "01ab58eb9dc64ceccb2d7be80ef4a511479fc899"
+SRCREV_machine_qemuppc ?= "c820da3c7fa5176507c116352ee3bd1e682f36bd"
+SRCREV_machine_qemux86 ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
+SRCREV_machine_qemux86-64 ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
+SRCREV_machine ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
+SRCREV_meta ?= "68a635bf8dfb64b02263c1ac80c948647cc76d5f"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
-- 
1.7.10.4

[PATCH 3/8] linux-yocto/3.4: bump kver to v3.4.16

[Bruce Ashfield]

The -stable 3.4 kernel has updated versions, so we import 3.4.16 and
make that our new baseline.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb   |    8 ++++----
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb |    6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.4.bb      |   16 ++++++++--------
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index bdbecf4..3ccd64a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH = "standard/preempt-rt/base"
 KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
 
-LINUX_VERSION ?= "3.4.11"
+LINUX_VERSION ?= "3.4.16"
 LINUX_KERNEL_TYPE = "preempt-rt"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "fb596148058bf5e7ef550a040d143bdfbf4146b0"
-SRCREV_machine_qemuppc ?= "b24ede45575d58ace08633f0e8fd31b594c5c80e"
-SRCREV_meta ?= "68a635bf8dfb64b02263c1ac80c948647cc76d5f"
+SRCREV_machine ?= "e9e1c1ef7b67464cb81b4c77bb9e97518851e2ad"
+SRCREV_machine_qemuppc ?= "6ce035a7528b710e0483d3d0a3f4e27e152bfccb"
+SRCREV_meta ?= "7c258779acffc9be33c7a31fa799dd416e9784a0"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
index 772cfef..e3c44ca 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
@@ -8,12 +8,12 @@ KBRANCH = "${KBRANCH_DEFAULT}"
 LINUX_KERNEL_TYPE = "tiny"
 KCONFIG_MODE = "--allnoconfig"
 
-LINUX_VERSION ?= "3.4.11"
+LINUX_VERSION ?= "3.4.16"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
-SRCREV_meta ?= "68a635bf8dfb64b02263c1ac80c948647cc76d5f"
+SRCREV_machine ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
+SRCREV_meta ?= "7c258779acffc9be33c7a31fa799dd416e9784a0"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 22593c6..156619e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH_DEFAULT = "standard/base"
 KBRANCH = "${KBRANCH_DEFAULT}"
 
-SRCREV_machine_qemuarm ?= "cec289be595a5889740ad4f0a58d12579f528d5e"
-SRCREV_machine_qemumips  ?= "01ab58eb9dc64ceccb2d7be80ef4a511479fc899"
-SRCREV_machine_qemuppc ?= "c820da3c7fa5176507c116352ee3bd1e682f36bd"
-SRCREV_machine_qemux86 ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
-SRCREV_machine_qemux86-64 ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
-SRCREV_machine ?= "218bd8d2022b9852c60d32f0d770931e3cf343e2"
-SRCREV_meta ?= "68a635bf8dfb64b02263c1ac80c948647cc76d5f"
+SRCREV_machine_qemuarm ?= "ca1bbde92c0d66ba8db6ac4654de12c0fbd5c0c8"
+SRCREV_machine_qemumips  ?= "c349c5fd5d9dc04b3983565c239805f2c30ce6ca"
+SRCREV_machine_qemuppc ?= "475a5e7d76f4e2914caefda3fed0adf40d0a2cc6"
+SRCREV_machine_qemux86 ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
+SRCREV_machine_qemux86-64 ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
+SRCREV_machine ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
+SRCREV_meta ?= "7c258779acffc9be33c7a31fa799dd416e9784a0"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
-LINUX_VERSION ?= "3.4.11"
+LINUX_VERSION ?= "3.4.16"
 
 PR = "${INC_PR}.3"
 PV = "${LINUX_VERSION}+git${SRCPV}"
-- 
1.7.10.4

[PATCH 4/8] linux-yocto/3.4: v3.4.17, v3.4.18, -rt and config changes

[Bruce Ashfield]

Bumping the linux-yocto/3.4 SRCREVs to incorporate the following updates:

  - v3.4.17
  - v3.4.18
  - 3.4.18-rt29

Also incorporating the following meta branch config changes:

  5bd6d0d rangeley: update include to use the new intel-dpdk feature
  4b277c2 dpdk: Add feature Intel DPDK
  3905e74 meta: rangeley: Enable Zlib Compression
  194c5f1 meta: Add a new feature for Zlib
  14cb04d meta: rangeley: Enable AES feature
  8e4dbf6 meta: Add new feature for Ciphers
  7e75c1f enable IPv6 Router Preference (RFC 4191) support
  dfd56d1 Create IPv4 and IPv6 IPSec fragments
  0a85061 rangeley: Add smp support
  1190856 rangeley: Add efi support
  b262e38 rangeley: Add PCI features
  80c9084 rangeley: Add uio and hugetlb support

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb   |    8 ++++----
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb |    6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.4.bb      |   16 ++++++++--------
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 3ccd64a..1176404 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH = "standard/preempt-rt/base"
 KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
 
-LINUX_VERSION ?= "3.4.16"
+LINUX_VERSION ?= "3.4.18"
 LINUX_KERNEL_TYPE = "preempt-rt"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "e9e1c1ef7b67464cb81b4c77bb9e97518851e2ad"
-SRCREV_machine_qemuppc ?= "6ce035a7528b710e0483d3d0a3f4e27e152bfccb"
-SRCREV_meta ?= "7c258779acffc9be33c7a31fa799dd416e9784a0"
+SRCREV_machine ?= "2572b13999da8129c37eb2bf7e9a8fa68dc2a4bf"
+SRCREV_machine_qemuppc ?= "2004632314104d4f31bb1577e955da53796f517c"
+SRCREV_meta ?= "553a8512fd924420db5cc2320ece4a6fd9b1e486"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
index e3c44ca..6cfec92 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb
@@ -8,12 +8,12 @@ KBRANCH = "${KBRANCH_DEFAULT}"
 LINUX_KERNEL_TYPE = "tiny"
 KCONFIG_MODE = "--allnoconfig"
 
-LINUX_VERSION ?= "3.4.16"
+LINUX_VERSION ?= "3.4.18"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
-SRCREV_meta ?= "7c258779acffc9be33c7a31fa799dd416e9784a0"
+SRCREV_machine ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
+SRCREV_meta ?= "553a8512fd924420db5cc2320ece4a6fd9b1e486"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 156619e..7a58e1c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH_DEFAULT = "standard/base"
 KBRANCH = "${KBRANCH_DEFAULT}"
 
-SRCREV_machine_qemuarm ?= "ca1bbde92c0d66ba8db6ac4654de12c0fbd5c0c8"
-SRCREV_machine_qemumips  ?= "c349c5fd5d9dc04b3983565c239805f2c30ce6ca"
-SRCREV_machine_qemuppc ?= "475a5e7d76f4e2914caefda3fed0adf40d0a2cc6"
-SRCREV_machine_qemux86 ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
-SRCREV_machine_qemux86-64 ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
-SRCREV_machine ?= "0d734af0fa4dbef33cb486e147dccf35c4ad0900"
-SRCREV_meta ?= "7c258779acffc9be33c7a31fa799dd416e9784a0"
+SRCREV_machine_qemuarm ?= "e24986bf7398f5fb471173bda1d4f32008da101a"
+SRCREV_machine_qemumips  ?= "8835a2ba0d8e8f9bb5e2513d3568ae3970acefd5"
+SRCREV_machine_qemuppc ?= "ae8e2cd14e47bceb9c2bdcb927b3a0ea61f6c311"
+SRCREV_machine_qemux86 ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
+SRCREV_machine_qemux86-64 ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
+SRCREV_machine ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
+SRCREV_meta ?= "553a8512fd924420db5cc2320ece4a6fd9b1e486"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
-LINUX_VERSION ?= "3.4.16"
+LINUX_VERSION ?= "3.4.18"
 
 PR = "${INC_PR}.3"
 PV = "${LINUX_VERSION}+git${SRCPV}"
-- 
1.7.10.4

[PATCH 5/8] linux-yocto/3.2: update to v3.2.32 and 3.2.32-rt48

[Bruce Ashfield]

The 3.2 kernel was lagging behind on kernel.org -stable and -rt
updates. Even though no 1.3 BSPs directly use this kernel, it should be
updated for those that may use it.

Sanity test on qemu* for -rt and standard builds.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb   |    8 ++++----
 meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb |    6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.2.bb      |   18 +++++++++---------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
index a3900ce..0c82e16 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH = "standard/preempt-rt/base"
 KBRANCH_qemuppc = "standard/preempt-rt/qemu-ppc32"
 
-LINUX_VERSION ?= "3.2.18"
+LINUX_VERSION ?= "3.2.32"
 LINUX_KERNEL_TYPE = "preempt-rt"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "c094363010bd4645e65cc8845dd23e513ac894d1"
-SRCREV_machine_qemuppc ?= "8e63a7522e4901c1312f7f53e490027070ffc057"
-SRCREV_meta ?= "486f7aec824b4127e91ef53228823e996b3696f0"
+SRCREV_machine ?= "d8f7347b67d909a999391c4b6f64447b0ccdc86a"
+SRCREV_machine_qemuppc ?= "65c57e1a8656830260aa56a25bc8512dcb68258a"
+SRCREV_meta ?= "e7f2fdc48f8808887175f0328274a2668084738c"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
index 2bd7eee..00f706b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
@@ -8,12 +8,12 @@ KBRANCH = "${KBRANCH_DEFAULT}"
 LINUX_KERNEL_TYPE = "tiny"
 KCONFIG_MODE = "--allnoconfig"
 
-LINUX_VERSION ?= "3.2.18"
+LINUX_VERSION ?= "3.2.32"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "da6291c46f37e2fb799d964c807d8d57ea89c375"
-SRCREV_meta ?= "486f7aec824b4127e91ef53228823e996b3696f0"
+SRCREV_machine ?= "c07ec7159c3ede723953b0d603a7bb55d8614b44"
+SRCREV_meta ?= "e7f2fdc48f8808887175f0328274a2668084738c"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.2.bb b/meta/recipes-kernel/linux/linux-yocto_3.2.bb
index 45414d5..77508fc 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.2.bb
@@ -7,15 +7,15 @@ KBRANCH_qemuppc  = "standard/default/qemu-ppc32"
 KBRANCH_qemumips = "standard/default/mti-malta32-be"
 KBRANCH_qemuarm  = "standard/default/arm-versatile-926ejs"
 
-LINUX_VERSION ?= "3.2.18"
-
-SRCREV_machine_qemuarm ?= "c721e94f7cd1b1ae7da5edc52076c771b2e9d134"
-SRCREV_machine_qemumips  ?= "2172812072c372cc704dac5e1654da81d6eabad3"
-SRCREV_machine_qemuppc ?= "800615ccdce45f6900b841954fa2f47987bb2a95"
-SRCREV_machine_qemux86 ?= "9e23973679d82a54dda697f539243fdea612e878"
-SRCREV_machine_qemux86-64 ?= "d7823aebcf7f724f50e30f245e5e71b3b4db1a0b"
-SRCREV_machine ?= "06882fc16a4e965872e7faacb91da1497efd9ac3"
-SRCREV_meta ?= "486f7aec824b4127e91ef53228823e996b3696f0"
+LINUX_VERSION ?= "3.2.32"
+
+SRCREV_machine_qemuarm ?= "ec68698f59bed87be4e13954d5d2b9dc1f314b45"
+SRCREV_machine_qemumips  ?= "ce21a2ab86277e410fd2229a10c45be6c9d0aa17"
+SRCREV_machine_qemuppc ?= "edd27681039f2077d83eb02d7c1c44afb7b6224f"
+SRCREV_machine_qemux86 ?= "2223d2fb00365c168ec380bdcbef05ef89751c85"
+SRCREV_machine_qemux86-64 ?= "2d7956d7e3d15f69c923315c175847813f353d39"
+SRCREV_machine ?= "6970a8f4f7caa2633aa1ae0b51732b246eb581ef"
+SRCREV_meta ?= "e7f2fdc48f8808887175f0328274a2668084738c"
 
 PR = "${INC_PR}.1"
 PV = "${LINUX_VERSION}+git${SRCPV}"
-- 
1.7.10.4

[PATCH 6/8] kern-tools: kconf_check: fix find warning

[Bruce Ashfield]

Bumping the kern-tools SRCREV to pickup the following change:

[
    kconf_check: fix find warning

    When searching for all available Kconfig files, kconf_check was using
    $meta_dir instead of $META_DIR. This resulted in a truncated path and
    the following warning:

      find: warning: -path $oe-path/linux/ will not match anything because it ends with /.

    Using the proper variable removes the warning and make sure that we
    do actually search all relevant directories.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
]

[YOCTO #3226]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 1381fd1..ce94885 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
 
 DEPENDS = "git-native guilt-native"
 
-SRCREV = "a04138a02644eada0d012196e5ac3db4f516114d"
+SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
 PR = "r12"
 PV = "0.1+git${SRCPV}"
 
-- 
1.7.10.4

[PATCH 7/8] kern-tools: flexibility and usability enhancements

[Bruce Ashfield]

Updating the SRCREV to import the following changes.

 [updateme: find the board description with the highest score]

   This removes the requirement that a custom linux-yocto .scc file have
   define KTYPE <foo>, where <foo> is typically "standard". The tools can
   now match on a .scc file that only matches the board, but will still
   chose one that matches the board and kernel type, if available.

 [updateme: allow for tabs or spaces in defines]

   define KMACHINE<tab>$MACHINE was missed by the regex.

 [scc/kgit-meta: detect and avoid duplicating patching]

   To allow feature description to be included multiple times, they were
   previously split into -enable and 'patch' descriptions. With this change
   the patches will be detected as already included, and skipped
   automatically. Removing the need to do this split. It also cleans up
   the ability to warn about multiple includes.

 [kconf_check: add "verify" configuration fragment type]

   This adds the ability for a BSP to have a kernel configuration
   fragment that lists options that must be present. If they are not
   present it is a hard error. "required" is a similar fragment, but
   it adds them to the build, and audits them at the end, but does
   not abort the build if they are present. This is a minor distinction,
   but one that is useful when creating flexible, shared kernel config
   structures.

 [kconf_check: improve kernel audit report formatting]
 [kconf_check: perform validity checks on non-hardware options]
 [kconf_check: cleanups and verbose flag]

   The existing output was verbose and not always useful to the reader.
   This change makes the output more compact, audits non-hardware options
   and gives information

     [invalid (54)]: meta/cfg/preempt-rt/common-pc/invalid.cfg
        This BSP sets config options that are not offered anywhere within this kernel

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index ce94885..f2cd39f 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
 
 DEPENDS = "git-native guilt-native"
 
-SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
+SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
 PR = "r12"
 PV = "0.1+git${SRCPV}"
 
-- 
1.7.10.4

[PATCH 8/8] guilt: change upstream tgz location

[Bruce Ashfield]

The kernel.org mirror of the guilt tarball has been missing for a while
and the yocto mirrors have been keeping builds working. Switching to a
debian upstream is better than solely relying on the yocto mirrors for
serving the tgz.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-devtools/guilt/guilt-native_0.33.bb |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/guilt/guilt-native_0.33.bb b/meta/recipes-devtools/guilt/guilt-native_0.33.bb
index 03763f7..754b528 100644
--- a/meta/recipes-devtools/guilt/guilt-native_0.33.bb
+++ b/meta/recipes-devtools/guilt/guilt-native_0.33.bb
@@ -4,11 +4,11 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b6f3400dc1a01cebafe8a52b3f344135"
 
 PV = "0.33"
-PR = "r1"
+PR = "r2"
 
 inherit native
 
-SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/people/jsipek/guilt/guilt-${PV}.tar.gz\
+SRC_URI = "http://ftp.de.debian.org/debian/pool/main/g/guilt/guilt_${PV}.orig.tar.gz\
            file://guilt-push.patch \
 	   file://guilt-pop.patch \
 	   file://guilt.patch \
-- 
1.7.10.4

Re: [PATCH 7/8] kern-tools: flexibility and usability enhancements

[Darren Hart]

On 11/14/2012 07:03 AM, Bruce Ashfield wrote:
> Updating the SRCREV to import the following changes.
> 
>  [updateme: find the board description with the highest score]
> 
>    This removes the requirement that a custom linux-yocto .scc file have
>    define KTYPE <foo>, where <foo> is typically "standard". The tools can
>    now match on a .scc file that only matches the board, but will still
>    chose one that matches the board and kernel type, if available.

Should the documentation then state that KTYPE is only necessary to
define if it is not "standard" ? Does this also apply to
linux-yocto-custom recipes/kernels where the repository could very well
not define any ktype at all?

> 
>  [updateme: allow for tabs or spaces in defines]
> 
>    define KMACHINE<tab>$MACHINE was missed by the regex.
> 
>  [scc/kgit-meta: detect and avoid duplicating patching]
> 
>    To allow feature description to be included multiple times, they were
>    previously split into -enable and 'patch' descriptions. With this change
>    the patches will be detected as already included, and skipped
>    automatically. Removing the need to do this split. It also cleans up
>    the ability to warn about multiple includes.
> 
>  [kconf_check: add "verify" configuration fragment type]
> 
>    This adds the ability for a BSP to have a kernel configuration
>    fragment that lists options that must be present. If they are not
>    present it is a hard error. "required" is a similar fragment, but
>    it adds them to the build, and audits them at the end, but does
>    not abort the build if they are present. This is a minor distinction,
>    but one that is useful when creating flexible, shared kernel config
>    structures.


IIRC we discussed this verify thing at ELCE and how it broke some of the
semantics.... trying to remember now, let's see:

kconf hardware foo.cfg
kconf verify hardware bar.cfg
kconf non-hardware foobar.cfg
kconf verify non-hardware barfoo.cfg

Is that how this is to be used? The configuration space just doubled
from a documentation point of view, and that is without even considering
the "required" keyword you described.

Can you use required with verify? Can you use both of them with both
hardware and non-hardware?


> 
>  [kconf_check: improve kernel audit report formatting]
>  [kconf_check: perform validity checks on non-hardware options]
>  [kconf_check: cleanups and verbose flag]
> 
>    The existing output was verbose and not always useful to the reader.
>    This change makes the output more compact, audits non-hardware options
>    and gives information
> 
>      [invalid (54)]: meta/cfg/preempt-rt/common-pc/invalid.cfg
>         This BSP sets config options that are not offered anywhere within this kernel
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index ce94885..f2cd39f 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
>  
>  DEPENDS = "git-native guilt-native"
>  
> -SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
> +SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
>  PR = "r12"
>  PV = "0.1+git${SRCPV}"
>  
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: [PATCH 7/8] kern-tools: flexibility and usability enhancements

[Bruce Ashfield]

On 12-11-14 11:33 AM, Darren Hart wrote:
>
>
> On 11/14/2012 07:03 AM, Bruce Ashfield wrote:
>> Updating the SRCREV to import the following changes.
>>
>>   [updateme: find the board description with the highest score]
>>
>>     This removes the requirement that a custom linux-yocto .scc file have
>>     define KTYPE <foo>, where <foo> is typically "standard". The tools can
>>     now match on a .scc file that only matches the board, but will still
>>     chose one that matches the board and kernel type, if available.
>
> Should the documentation then state that KTYPE is only necessary to
> define if it is not "standard" ? Does this also apply to

Nope. That isn't the intention. If you are using kernel types at all,
you should define one. Whether it be standard or not.

> linux-yocto-custom recipes/kernels where the repository could very well
> not define any ktype at all?

Same as the above. If you are create kernel .scc files to work with
linux-yocto custom, you are now free to use kernel types, or not, your
choice.

>
>>
>>   [updateme: allow for tabs or spaces in defines]
>>
>>     define KMACHINE<tab>$MACHINE was missed by the regex.
>>
>>   [scc/kgit-meta: detect and avoid duplicating patching]
>>
>>     To allow feature description to be included multiple times, they were
>>     previously split into -enable and 'patch' descriptions. With this change
>>     the patches will be detected as already included, and skipped
>>     automatically. Removing the need to do this split. It also cleans up
>>     the ability to warn about multiple includes.
>>
>>   [kconf_check: add "verify" configuration fragment type]
>>
>>     This adds the ability for a BSP to have a kernel configuration
>>     fragment that lists options that must be present. If they are not
>>     present it is a hard error. "required" is a similar fragment, but
>>     it adds them to the build, and audits them at the end, but does
>>     not abort the build if they are present. This is a minor distinction,
>>     but one that is useful when creating flexible, shared kernel config
>>     structures.
>
>
> IIRC we discussed this verify thing at ELCE and how it broke some of the
> semantics.... trying to remember now, let's see:
>
> kconf hardware foo.cfg
> kconf verify hardware bar.cfg
> kconf non-hardware foobar.cfg
> kconf verify non-hardware barfoo.cfg
>
> Is that how this is to be used? The configuration space just doubled
> from a documentation point of view, and that is without even considering
> the "required" keyword you described.

I'll continue to work on this for 1.4, but I didn't want to pend the
series on anything that we discussed in Barcelona .. these have been
around for some time and I wanted to push them out before doing any 1.4
tweaks.

But to answer your question. You could have multiple 'verify' fragments,
but I'd only suggest one. It's a final check that critical options are
in the final .config and will throw a hard error. required is an
alias for 'hardware' and still only throws a warning if they are missing.

There few current users of 'verify', so I can still follow up with
syntax tweaks that we discussed (do you have notes on that ?). I recall
simply making 'verify' a modifier of the existing kconf types would be
better than the current new type. I'll keep all the variants around, since
the plumbing is the same and that will again give time for migration.

We could argue that required should also be a hard error, but we can't
do that quite yet, since there are some existing use cases and trees
that will start to error out, and I'd like to migrate them first.

>
> Can you use required with verify? Can you use both of them with both
> hardware and non-hardware?

Any combination at all should work.

Cheers,

Bruce

>
>
>>
>>   [kconf_check: improve kernel audit report formatting]
>>   [kconf_check: perform validity checks on non-hardware options]
>>   [kconf_check: cleanups and verbose flag]
>>
>>     The existing output was verbose and not always useful to the reader.
>>     This change makes the output more compact, audits non-hardware options
>>     and gives information
>>
>>       [invalid (54)]: meta/cfg/preempt-rt/common-pc/invalid.cfg
>>          This BSP sets config options that are not offered anywhere within this kernel
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>   meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> index ce94885..f2cd39f 100644
>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
>>
>>   DEPENDS = "git-native guilt-native"
>>
>> -SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
>> +SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
>>   PR = "r12"
>>   PV = "0.1+git${SRCPV}"
>>
>>
>

Re: [PATCH 7/8] kern-tools: flexibility and usability enhancements

[Darren Hart]

On 11/14/2012 08:58 AM, Bruce Ashfield wrote:
> On 12-11-14 11:33 AM, Darren Hart wrote:
>>
>>
>> On 11/14/2012 07:03 AM, Bruce Ashfield wrote:
>>> Updating the SRCREV to import the following changes.
>>>
>>>   [updateme: find the board description with the highest score]
>>>
>>>     This removes the requirement that a custom linux-yocto .scc file have
>>>     define KTYPE <foo>, where <foo> is typically "standard". The tools can
>>>     now match on a .scc file that only matches the board, but will still
>>>     chose one that matches the board and kernel type, if available.
>>
>> Should the documentation then state that KTYPE is only necessary to
>> define if it is not "standard" ? Does this also apply to
> 
> Nope. That isn't the intention. If you are using kernel types at all,
> you should define one. Whether it be standard or not.
> 
>> linux-yocto-custom recipes/kernels where the repository could very well
>> not define any ktype at all?
> 
> Same as the above. If you are create kernel .scc files to work with
> linux-yocto custom, you are now free to use kernel types, or not, your
> choice.

And what happens if they don't? It will just match on KMACHINE? Making
it so you can define one defconfig per machine and be done with it?
(if that's what you really wanted to do).


> 
>>
>>>
>>>   [updateme: allow for tabs or spaces in defines]
>>>
>>>     define KMACHINE<tab>$MACHINE was missed by the regex.
>>>
>>>   [scc/kgit-meta: detect and avoid duplicating patching]
>>>
>>>     To allow feature description to be included multiple times, they were
>>>     previously split into -enable and 'patch' descriptions. With this change
>>>     the patches will be detected as already included, and skipped
>>>     automatically. Removing the need to do this split. It also cleans up
>>>     the ability to warn about multiple includes.
>>>
>>>   [kconf_check: add "verify" configuration fragment type]
>>>
>>>     This adds the ability for a BSP to have a kernel configuration
>>>     fragment that lists options that must be present. If they are not
>>>     present it is a hard error. "required" is a similar fragment, but
>>>     it adds them to the build, and audits them at the end, but does
>>>     not abort the build if they are present. This is a minor distinction,
>>>     but one that is useful when creating flexible, shared kernel config
>>>     structures.
>>
>>
>> IIRC we discussed this verify thing at ELCE and how it broke some of the
>> semantics.... trying to remember now, let's see:
>>
>> kconf hardware foo.cfg
>> kconf verify hardware bar.cfg
>> kconf non-hardware foobar.cfg
>> kconf verify non-hardware barfoo.cfg
>>
>> Is that how this is to be used? The configuration space just doubled
>> from a documentation point of view, and that is without even considering
>> the "required" keyword you described.
> 
> I'll continue to work on this for 1.4, but I didn't want to pend the
> series on anything that we discussed in Barcelona .. these have been
> around for some time and I wanted to push them out before doing any 1.4
> tweaks.
> 
> But to answer your question. You could have multiple 'verify' fragments,
> but I'd only suggest one. It's a final check that critical options are
> in the final .config and will throw a hard error. required is an
> alias for 'hardware' and still only throws a warning if they are missing.
> 
> There few current users of 'verify', so I can still follow up with
> syntax tweaks that we discussed (do you have notes on that ?). I recall
> simply making 'verify' a modifier of the existing kconf types would be
> better than the current new type. I'll keep all the variants around, since
> the plumbing is the same and that will again give time for migration.
> 
> We could argue that required should also be a hard error, but we can't
> do that quite yet, since there are some existing use cases and trees
> that will start to error out, and I'd like to migrate them first.


I don't seem to have any notes on this for some reason. I'm wondering if
instead of modifiers, these should just be kconf types:

non-hardware
hardware
required
verify

As you said, required is an alias to hardware, so it isn't really a
modifier. And verify is less of a modifier and more of a verification
step, so it doesn't matter if it's hardware or non-hardware.

This would reduce the config space from 6 to 4, not a huge savings,
but it would be much simpler to document.

I'm going to omit these from the docs for now though.

> 
>>
>> Can you use required with verify? Can you use both of them with both
>> hardware and non-hardware?
> 
> Any combination at all should work.
> 
> Cheers,
> 
> Bruce
> 
>>
>>
>>>
>>>   [kconf_check: improve kernel audit report formatting]
>>>   [kconf_check: perform validity checks on non-hardware options]
>>>   [kconf_check: cleanups and verbose flag]
>>>
>>>     The existing output was verbose and not always useful to the reader.
>>>     This change makes the output more compact, audits non-hardware options
>>>     and gives information
>>>
>>>       [invalid (54)]: meta/cfg/preempt-rt/common-pc/invalid.cfg
>>>          This BSP sets config options that are not offered anywhere within this kernel
>>>
>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>> ---
>>>   meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> index ce94885..f2cd39f 100644
>>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
>>>
>>>   DEPENDS = "git-native guilt-native"
>>>
>>> -SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
>>> +SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
>>>   PR = "r12"
>>>   PV = "0.1+git${SRCPV}"
>>>
>>>
>>
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: [PATCH 7/8] kern-tools: flexibility and usability enhancements

[Bruce Ashfield]

On 12-11-14 12:09 PM, Darren Hart wrote:
>
>
> On 11/14/2012 08:58 AM, Bruce Ashfield wrote:
>> On 12-11-14 11:33 AM, Darren Hart wrote:
>>>
>>>
>>> On 11/14/2012 07:03 AM, Bruce Ashfield wrote:
>>>> Updating the SRCREV to import the following changes.
>>>>
>>>>    [updateme: find the board description with the highest score]
>>>>
>>>>      This removes the requirement that a custom linux-yocto .scc file have
>>>>      define KTYPE <foo>, where <foo> is typically "standard". The tools can
>>>>      now match on a .scc file that only matches the board, but will still
>>>>      chose one that matches the board and kernel type, if available.
>>>
>>> Should the documentation then state that KTYPE is only necessary to
>>> define if it is not "standard" ? Does this also apply to
>>
>> Nope. That isn't the intention. If you are using kernel types at all,
>> you should define one. Whether it be standard or not.
>>
>>> linux-yocto-custom recipes/kernels where the repository could very well
>>> not define any ktype at all?
>>
>> Same as the above. If you are create kernel .scc files to work with
>> linux-yocto custom, you are now free to use kernel types, or not, your
>> choice.
>
> And what happens if they don't? It will just match on KMACHINE? Making
> it so you can define one defconfig per machine and be done with it?
> (if that's what you really wanted to do).

Correct. It matches the .scc file that scores the best. If you don't
have a kernel type and a .scc file matches the KMACHINE that's the
one it'll use. If you want more separation, then you can start using
KTYPE without modifying the existing .scc files, since one with
a matching KMACHINE/KTYPE will score higher than the KMACHINE only
.scc file.

>
>
>>
>>>
>>>>
>>>>    [updateme: allow for tabs or spaces in defines]
>>>>
>>>>      define KMACHINE<tab>$MACHINE was missed by the regex.
>>>>
>>>>    [scc/kgit-meta: detect and avoid duplicating patching]
>>>>
>>>>      To allow feature description to be included multiple times, they were
>>>>      previously split into -enable and 'patch' descriptions. With this change
>>>>      the patches will be detected as already included, and skipped
>>>>      automatically. Removing the need to do this split. It also cleans up
>>>>      the ability to warn about multiple includes.
>>>>
>>>>    [kconf_check: add "verify" configuration fragment type]
>>>>
>>>>      This adds the ability for a BSP to have a kernel configuration
>>>>      fragment that lists options that must be present. If they are not
>>>>      present it is a hard error. "required" is a similar fragment, but
>>>>      it adds them to the build, and audits them at the end, but does
>>>>      not abort the build if they are present. This is a minor distinction,
>>>>      but one that is useful when creating flexible, shared kernel config
>>>>      structures.
>>>
>>>
>>> IIRC we discussed this verify thing at ELCE and how it broke some of the
>>> semantics.... trying to remember now, let's see:
>>>
>>> kconf hardware foo.cfg
>>> kconf verify hardware bar.cfg
>>> kconf non-hardware foobar.cfg
>>> kconf verify non-hardware barfoo.cfg
>>>
>>> Is that how this is to be used? The configuration space just doubled
>>> from a documentation point of view, and that is without even considering
>>> the "required" keyword you described.
>>
>> I'll continue to work on this for 1.4, but I didn't want to pend the
>> series on anything that we discussed in Barcelona .. these have been
>> around for some time and I wanted to push them out before doing any 1.4
>> tweaks.
>>
>> But to answer your question. You could have multiple 'verify' fragments,
>> but I'd only suggest one. It's a final check that critical options are
>> in the final .config and will throw a hard error. required is an
>> alias for 'hardware' and still only throws a warning if they are missing.
>>
>> There few current users of 'verify', so I can still follow up with
>> syntax tweaks that we discussed (do you have notes on that ?). I recall
>> simply making 'verify' a modifier of the existing kconf types would be
>> better than the current new type. I'll keep all the variants around, since
>> the plumbing is the same and that will again give time for migration.
>>
>> We could argue that required should also be a hard error, but we can't
>> do that quite yet, since there are some existing use cases and trees
>> that will start to error out, and I'd like to migrate them first.
>
>
> I don't seem to have any notes on this for some reason. I'm wondering if
> instead of modifiers, these should just be kconf types:
>
> non-hardware
> hardware
> required
> verify
>
> As you said, required is an alias to hardware, so it isn't really a
> modifier. And verify is less of a modifier and more of a verification
> step, so it doesn't matter if it's hardware or non-hardware.
>
> This would reduce the config space from 6 to 4, not a huge savings,
> but it would be much simpler to document.

Agreed, I'll put this into bugzilla and document what we'll do for
1.4 as the final syntax.

>
> I'm going to omit these from the docs for now though.
>

Sounds good. We'll nail them down first and then document it :)

Cheers,

Bruce

>>
>>>
>>> Can you use required with verify? Can you use both of them with both
>>> hardware and non-hardware?
>>
>> Any combination at all should work.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>
>>>>
>>>>    [kconf_check: improve kernel audit report formatting]
>>>>    [kconf_check: perform validity checks on non-hardware options]
>>>>    [kconf_check: cleanups and verbose flag]
>>>>
>>>>      The existing output was verbose and not always useful to the reader.
>>>>      This change makes the output more compact, audits non-hardware options
>>>>      and gives information
>>>>
>>>>        [invalid (54)]: meta/cfg/preempt-rt/common-pc/invalid.cfg
>>>>           This BSP sets config options that are not offered anywhere within this kernel
>>>>
>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>> ---
>>>>    meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>>> index ce94885..f2cd39f 100644
>>>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>>> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
>>>>
>>>>    DEPENDS = "git-native guilt-native"
>>>>
>>>> -SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
>>>> +SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
>>>>    PR = "r12"
>>>>    PV = "0.1+git${SRCPV}"
>>>>
>>>>
>>>
>>
>

Re: [PATCH 0/8] linux-yocto + kern tools consolidated pull request

[Saul Wold]

On 11/14/2012 07:02 AM, Bruce Ashfield wrote:
> Richard/Saul,
>
> This is a collection of updates that I've had locally in the last few
> weeks leading up to the 1.3 release, but they were held back to avoid
> any negative impacts on the release.
>
> I've kept all the kernel -stable and configuration updates as distinct
> commits, so it will be possible to separate any issues that crop up
> into manageable chunks. It also shows the different test points that
> I've used while updating the kernels.
>
> For the kernel trees we get the following:
>
>    - the latest 3.2 and 3.4 -stable updates
>    - the latest 3.2 and 3.4 -rt updates
>    - configuration changes that have been collected for BSPs
>
>    ** As far as I'm concerned these are all bugfix/stable changes and
>       can go into danny-next. Others may not agree :)
>
> These have been build tested to the amount that my cycles allow, and
> others have already been used in the meta-intel BSPs. It's worth running
> this through a test build if you are so inclined, just to be sure.
>
> For the tools we get the following updates:
>
>    - A fix for YOCTO #3226 that silences the warning:
>
>         find: warning: -path $oe-path/linux/ will not match anything because it ends with /.
>
>      ** This change should be considering for the danny-next branch as well.
>
>    - A fix to the guilt SRC_URI to point at a valid tgz upstream.
>
>      ** This change should be considering for the danny-next branch as well.
>
>    - kern-tools improvements and fixes that are part of the 1.4 feature work.
>      The kern-tools commit has the details of the changes. They'll be further
>      improved in the upcoming weeks, but they have been in use locally for
>      over a month now, and have been tested by others as well, so they shouldn't
>      cause any problems in master and are invisible to most users.
>
> I've added Ross to the CC for the commits that can be pulled into the 1.3
> maintenance branches.
>
> I've added Rahul since there was some refactoring of the Rangely/dpdk
> configuration that should be checked as well.
>
> Cheers,
>
> Bruce
>
> The following changes since commit 41125ddc8651494ffcf888d3b5efce1ae6d953bb:
>
>    bitbake: print clear message for "bitbake -e ASSUME_PROVIDED" (2012-11-13 14:21:16 +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 (8):
>    linux-yocto/3.4: nfsd, pci, fishriver and rangely config changes
>    linux-yocto/3.4: efi/mmc fixes and fri2 updates
>    linux-yocto/3.4: bump kver to v3.4.16
>    linux-yocto/3.4: v3.4.17, v3.4.18, -rt and config changes
>    linux-yocto/3.2: update to v3.2.32 and 3.2.32-rt48
>    kern-tools: kconf_check: fix find warning
>    kern-tools: flexibility and usability enhancements
>    guilt: change upstream tgz location
>
>   meta/recipes-devtools/guilt/guilt-native_0.33.bb     |    4 ++--
>   .../kern-tools/kern-tools-native_git.bb              |    2 +-
>   meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb      |    8 ++++----
>   meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb      |    8 ++++----
>   meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb    |    6 +++---
>   meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb    |    7 +++----
>   meta/recipes-kernel/linux/linux-yocto_3.2.bb         |   18 +++++++++---------
>   meta/recipes-kernel/linux/linux-yocto_3.4.bb         |   16 ++++++++--------
>   8 files changed, 34 insertions(+), 35 deletions(-)
>

Merged into OE-Core

Thanks
	Sau!