[PATCH v2] Install kernel via replaceable recipe

[PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This simplifies the common task of using a custom kernel instead of the
pre-selected debian variant: Move the kernel installation into a dummy
dpkg-raw recipe that only has the kernel package as dependency.

Which recipe is used for providing the kernel can now be selected via
the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.

The kernel package name is communicated from the target multiconfig file
to the linux-debian recipe via the DEBIAN_KERNEL variable.

Based on an idea of Henning Schild.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

Changes in v2:
 - install kernel meta package from local repo, instead of trying to
   pre-install it from the upstream one
   (I swear I tested this and it worked, but I have no idea how it
   could...)

 meta-isar/conf/multiconfig/qemuamd64-jessie.conf  |  2 +-
 meta-isar/conf/multiconfig/qemuamd64-stretch.conf |  3 ++-
 meta-isar/conf/multiconfig/qemuarm-jessie.conf    |  2 +-
 meta-isar/conf/multiconfig/qemuarm-stretch.conf   |  3 ++-
 meta-isar/conf/multiconfig/qemuarm-wheezy.conf    |  2 +-
 meta-isar/conf/multiconfig/qemui386-jessie.conf   |  2 +-
 meta-isar/conf/multiconfig/qemui386-stretch.conf  |  3 ++-
 meta-isar/conf/multiconfig/rpi-jessie.conf        |  3 ++-
 meta-isar/recipes-core/images/isar-image-base.bb  |  7 ++++++-
 meta-isar/recipes-kernel/linux/linux-debian.bb    | 12 ++++++++++++
 10 files changed, 30 insertions(+), 9 deletions(-)
 create mode 100644 meta-isar/recipes-kernel/linux/linux-debian.bb

diff --git a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
index 51d39b6..e49751f 100644
--- a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
+++ b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
@@ -6,7 +6,7 @@ MACHINE ?= "qemuamd64"
 DISTRO ?= "debian-jessie"
 DISTRO_ARCH ?= "amd64"
 
-IMAGE_PREINSTALL += "linux-image-amd64"
+DEBIAN_KERNEL ?= "linux-image-amd64"
 
 ROOTFS_DEV ?= "sda"
 
diff --git a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
index c59876a..f3dcd3a 100644
--- a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
+++ b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
@@ -8,9 +8,10 @@ DISTRO_ARCH ?= "amd64"
 
 IMAGE_PREINSTALL += " \
     init \
-    linux-image-amd64 \
 "
 
+DEBIAN_KERNEL ?= "linux-image-amd64"
+
 ROOTFS_DEV ?= "sda"
 
 QEMU_ARCH ?= "x86_64"
diff --git a/meta-isar/conf/multiconfig/qemuarm-jessie.conf b/meta-isar/conf/multiconfig/qemuarm-jessie.conf
index ed84c6c..50a27f5 100644
--- a/meta-isar/conf/multiconfig/qemuarm-jessie.conf
+++ b/meta-isar/conf/multiconfig/qemuarm-jessie.conf
@@ -13,7 +13,7 @@ MACHINE ?= "qemuarm"
 DISTRO ?= "debian-jessie"
 DISTRO_ARCH ?= "armhf"
 
-IMAGE_PREINSTALL += "linux-image-armmp"
+DEBIAN_KERNEL ?= "linux-image-armmp"
 
 ROOTFS_DEV ?= "vda"
 
diff --git a/meta-isar/conf/multiconfig/qemuarm-stretch.conf b/meta-isar/conf/multiconfig/qemuarm-stretch.conf
index 1cce97a..9b99fb0 100644
--- a/meta-isar/conf/multiconfig/qemuarm-stretch.conf
+++ b/meta-isar/conf/multiconfig/qemuarm-stretch.conf
@@ -8,9 +8,10 @@ DISTRO_ARCH ?= "armhf"
 
 IMAGE_PREINSTALL += " \
     init \
-    linux-image-armmp \
 "
 
+DEBIAN_KERNEL ?= "linux-image-armmp"
+
 ROOTFS_DEV ?= "vda"
 
 QEMU_ARCH ?= "arm"
diff --git a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
index 38ea191..ab163a2 100644
--- a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
+++ b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
@@ -13,7 +13,7 @@ MACHINE ?= "qemuarm"
 DISTRO ?= "debian-wheezy"
 DISTRO_ARCH ?= "armhf"
 
-IMAGE_PREINSTALL += "linux-image-vexpress"
+DEBIAN_KERNEL ?= "linux-image-vexpress"
 
 ROOTFS_DEV ?= "mmcblk0"
 
diff --git a/meta-isar/conf/multiconfig/qemui386-jessie.conf b/meta-isar/conf/multiconfig/qemui386-jessie.conf
index d589661..e3df61d 100644
--- a/meta-isar/conf/multiconfig/qemui386-jessie.conf
+++ b/meta-isar/conf/multiconfig/qemui386-jessie.conf
@@ -6,7 +6,7 @@ MACHINE ?= "qemui386"
 DISTRO ?= "debian-jessie"
 DISTRO_ARCH ?= "i386"
 
-IMAGE_PREINSTALL += "linux-image-686-pae"
+DEBIAN_KERNEL ?= "linux-image-686-pae"
 
 ROOTFS_DEV ?= "sda"
 
diff --git a/meta-isar/conf/multiconfig/qemui386-stretch.conf b/meta-isar/conf/multiconfig/qemui386-stretch.conf
index 40239e4..344783e 100644
--- a/meta-isar/conf/multiconfig/qemui386-stretch.conf
+++ b/meta-isar/conf/multiconfig/qemui386-stretch.conf
@@ -8,9 +8,10 @@ DISTRO_ARCH ?= "i386"
 
 IMAGE_PREINSTALL += " \
     init \
-    linux-image-686-pae \
 "
 
+DEBIAN_KERNEL ?= "linux-image-686-pae"
+
 ROOTFS_DEV ?= "sda"
 
 QEMU_ARCH ?= "i386"
diff --git a/meta-isar/conf/multiconfig/rpi-jessie.conf b/meta-isar/conf/multiconfig/rpi-jessie.conf
index d1dd9d9..cfbeb3a 100644
--- a/meta-isar/conf/multiconfig/rpi-jessie.conf
+++ b/meta-isar/conf/multiconfig/rpi-jessie.conf
@@ -19,7 +19,6 @@ IMAGE_PREINSTALL += " \
     iproute2 \
     iputils-ping \
     isc-dhcp-client \
-    linux-image-rpi-rpfv \
     lrzsz \
     net-tools \
     netcat-openbsd \
@@ -31,4 +30,6 @@ IMAGE_PREINSTALL += " \
     vim \
     "
 
+DEBIAN_KERNEL ?= "linux-image-rpi-rpfv"
+
 ROOTFS_DEV ?= "mmcblk0p2"
diff --git a/meta-isar/recipes-core/images/isar-image-base.bb b/meta-isar/recipes-core/images/isar-image-base.bb
index e359ac3..2f03cd1 100644
--- a/meta-isar/recipes-core/images/isar-image-base.bb
+++ b/meta-isar/recipes-core/images/isar-image-base.bb
@@ -18,12 +18,17 @@ PV = "1.0"
 
 inherit image
 
-DEPENDS += "${IMAGE_INSTALL}"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-debian"
+
+DEPENDS += "${IMAGE_INSTALL} \
+            virtual/kernel"
 
 IMAGE_PREINSTALL += "apt \
                      dbus \
                      localepurge"
 
+IMAGE_INSTALL += "${@d.getVar("PREFERRED_PROVIDER_virtual/kernel", True)}"
+
 WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
 
 do_rootfs[dirs] = "${WORKDIR}/hooks_multistrap"
diff --git a/meta-isar/recipes-kernel/linux/linux-debian.bb b/meta-isar/recipes-kernel/linux/linux-debian.bb
new file mode 100644
index 0000000..21d20c2
--- /dev/null
+++ b/meta-isar/recipes-kernel/linux/linux-debian.bb
@@ -0,0 +1,12 @@
+# Debian kernel pseudo package
+#
+# This software is a part of ISAR.
+# Copyright (c) Siemens AG, 2018
+
+DESCRIPTION = "Prebuilt Debian kernel"
+MAINTAINER = "ISAR project"
+PROVIDES = "virtual/kernel"
+
+DEBIAN_DEPENDS = "${DEBIAN_KERNEL}"
+
+inherit dpkg-raw
-- 
2.13.6

Re: [PATCH v2] Install kernel via replaceable recipe

[Henning Schild]

This one looks useful but i would like to see it in context with the
actual replacement kernel.

Am Tue, 30 Jan 2018 10:34:45 +0100
schrieb "Jan Kiszka" <jan.kiszka@siemens.com>:

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This simplifies the common task of using a custom kernel instead of
> the pre-selected debian variant: Move the kernel installation into a
> dummy dpkg-raw recipe that only has the kernel package as dependency.
> 
> Which recipe is used for providing the kernel can now be selected via
> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
> 
> The kernel package name is communicated from the target multiconfig
> file to the linux-debian recipe via the DEBIAN_KERNEL variable.
> 
> Based on an idea of Henning Schild.

Really ? I don't remember. 

> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Changes in v2:
>  - install kernel meta package from local repo, instead of trying to
>    pre-install it from the upstream one
>    (I swear I tested this and it worked, but I have no idea how it
>    could...)
> 
>  meta-isar/conf/multiconfig/qemuamd64-jessie.conf  |  2 +-
>  meta-isar/conf/multiconfig/qemuamd64-stretch.conf |  3 ++-
>  meta-isar/conf/multiconfig/qemuarm-jessie.conf    |  2 +-
>  meta-isar/conf/multiconfig/qemuarm-stretch.conf   |  3 ++-
>  meta-isar/conf/multiconfig/qemuarm-wheezy.conf    |  2 +-
>  meta-isar/conf/multiconfig/qemui386-jessie.conf   |  2 +-
>  meta-isar/conf/multiconfig/qemui386-stretch.conf  |  3 ++-
>  meta-isar/conf/multiconfig/rpi-jessie.conf        |  3 ++-
>  meta-isar/recipes-core/images/isar-image-base.bb  |  7 ++++++-
>  meta-isar/recipes-kernel/linux/linux-debian.bb    | 12 ++++++++++++
>  10 files changed, 30 insertions(+), 9 deletions(-)
>  create mode 100644 meta-isar/recipes-kernel/linux/linux-debian.bb
> 
> diff --git a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
> b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf index
> 51d39b6..e49751f 100644 ---
> a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf +++
> b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf @@ -6,7 +6,7 @@
> MACHINE ?= "qemuamd64" DISTRO ?= "debian-jessie"
>  DISTRO_ARCH ?= "amd64"
>  
> -IMAGE_PREINSTALL += "linux-image-amd64"
> +DEBIAN_KERNEL ?= "linux-image-amd64"
>  
>  ROOTFS_DEV ?= "sda"
>  
> diff --git a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
> b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf index
> c59876a..f3dcd3a 100644 ---
> a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf +++
> b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf @@ -8,9 +8,10 @@
> DISTRO_ARCH ?= "amd64" 
>  IMAGE_PREINSTALL += " \
>      init \
> -    linux-image-amd64 \
>  "
>  
> +DEBIAN_KERNEL ?= "linux-image-amd64"
> +
>  ROOTFS_DEV ?= "sda"
>  
>  QEMU_ARCH ?= "x86_64"
> diff --git a/meta-isar/conf/multiconfig/qemuarm-jessie.conf
> b/meta-isar/conf/multiconfig/qemuarm-jessie.conf index
> ed84c6c..50a27f5 100644 ---
> a/meta-isar/conf/multiconfig/qemuarm-jessie.conf +++
> b/meta-isar/conf/multiconfig/qemuarm-jessie.conf @@ -13,7 +13,7 @@
> MACHINE ?= "qemuarm" DISTRO ?= "debian-jessie"
>  DISTRO_ARCH ?= "armhf"
>  
> -IMAGE_PREINSTALL += "linux-image-armmp"
> +DEBIAN_KERNEL ?= "linux-image-armmp"
>  
>  ROOTFS_DEV ?= "vda"
>  
> diff --git a/meta-isar/conf/multiconfig/qemuarm-stretch.conf
> b/meta-isar/conf/multiconfig/qemuarm-stretch.conf index
> 1cce97a..9b99fb0 100644 ---
> a/meta-isar/conf/multiconfig/qemuarm-stretch.conf +++
> b/meta-isar/conf/multiconfig/qemuarm-stretch.conf @@ -8,9 +8,10 @@
> DISTRO_ARCH ?= "armhf" 
>  IMAGE_PREINSTALL += " \
>      init \
> -    linux-image-armmp \
>  "
>  
> +DEBIAN_KERNEL ?= "linux-image-armmp"
> +
>  ROOTFS_DEV ?= "vda"
>  
>  QEMU_ARCH ?= "arm"
> diff --git a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
> b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf index
> 38ea191..ab163a2 100644 ---
> a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf +++
> b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf @@ -13,7 +13,7 @@
> MACHINE ?= "qemuarm" DISTRO ?= "debian-wheezy"
>  DISTRO_ARCH ?= "armhf"
>  
> -IMAGE_PREINSTALL += "linux-image-vexpress"
> +DEBIAN_KERNEL ?= "linux-image-vexpress"
>  
>  ROOTFS_DEV ?= "mmcblk0"
>  
> diff --git a/meta-isar/conf/multiconfig/qemui386-jessie.conf
> b/meta-isar/conf/multiconfig/qemui386-jessie.conf index
> d589661..e3df61d 100644 ---
> a/meta-isar/conf/multiconfig/qemui386-jessie.conf +++
> b/meta-isar/conf/multiconfig/qemui386-jessie.conf @@ -6,7 +6,7 @@
> MACHINE ?= "qemui386" DISTRO ?= "debian-jessie"
>  DISTRO_ARCH ?= "i386"
>  
> -IMAGE_PREINSTALL += "linux-image-686-pae"
> +DEBIAN_KERNEL ?= "linux-image-686-pae"
>  
>  ROOTFS_DEV ?= "sda"
>  
> diff --git a/meta-isar/conf/multiconfig/qemui386-stretch.conf
> b/meta-isar/conf/multiconfig/qemui386-stretch.conf index
> 40239e4..344783e 100644 ---
> a/meta-isar/conf/multiconfig/qemui386-stretch.conf +++
> b/meta-isar/conf/multiconfig/qemui386-stretch.conf @@ -8,9 +8,10 @@
> DISTRO_ARCH ?= "i386" 
>  IMAGE_PREINSTALL += " \
>      init \
> -    linux-image-686-pae \
>  "
>  
> +DEBIAN_KERNEL ?= "linux-image-686-pae"
> +
>  ROOTFS_DEV ?= "sda"
>  
>  QEMU_ARCH ?= "i386"
> diff --git a/meta-isar/conf/multiconfig/rpi-jessie.conf
> b/meta-isar/conf/multiconfig/rpi-jessie.conf index d1dd9d9..cfbeb3a
> 100644 --- a/meta-isar/conf/multiconfig/rpi-jessie.conf
> +++ b/meta-isar/conf/multiconfig/rpi-jessie.conf
> @@ -19,7 +19,6 @@ IMAGE_PREINSTALL += " \
>      iproute2 \
>      iputils-ping \
>      isc-dhcp-client \
> -    linux-image-rpi-rpfv \
>      lrzsz \
>      net-tools \
>      netcat-openbsd \
> @@ -31,4 +30,6 @@ IMAGE_PREINSTALL += " \
>      vim \
>      "
>  
> +DEBIAN_KERNEL ?= "linux-image-rpi-rpfv"
> +
>  ROOTFS_DEV ?= "mmcblk0p2"
> diff --git a/meta-isar/recipes-core/images/isar-image-base.bb
> b/meta-isar/recipes-core/images/isar-image-base.bb index
> e359ac3..2f03cd1 100644 ---
> a/meta-isar/recipes-core/images/isar-image-base.bb +++
> b/meta-isar/recipes-core/images/isar-image-base.bb @@ -18,12 +18,17
> @@ PV = "1.0" 
>  inherit image
>  
> -DEPENDS += "${IMAGE_INSTALL}"
> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-debian"
> +
> +DEPENDS += "${IMAGE_INSTALL} \
> +            virtual/kernel"
>  
>  IMAGE_PREINSTALL += "apt \
>                       dbus \
>                       localepurge"
>  
> +IMAGE_INSTALL += "${@d.getVar("PREFERRED_PROVIDER_virtual/kernel",
> True)}" +
>  WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
>  
>  do_rootfs[dirs] = "${WORKDIR}/hooks_multistrap"
> diff --git a/meta-isar/recipes-kernel/linux/linux-debian.bb
> b/meta-isar/recipes-kernel/linux/linux-debian.bb new file mode 100644
> index 0000000..21d20c2
> --- /dev/null
> +++ b/meta-isar/recipes-kernel/linux/linux-debian.bb
> @@ -0,0 +1,12 @@
> +# Debian kernel pseudo package
> +#
> +# This software is a part of ISAR.
> +# Copyright (c) Siemens AG, 2018
> +
> +DESCRIPTION = "Prebuilt Debian kernel"
> +MAINTAINER = "ISAR project"

Please include an email address here.

https://www.debian.org/doc/debian-policy/#s-f-maintainer

Henning

> +PROVIDES = "virtual/kernel"
> +
> +DEBIAN_DEPENDS = "${DEBIAN_KERNEL}"
> +
> +inherit dpkg-raw

Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka]

On 2018-01-30 11:31, Henning Schild wrote:
> This one looks useful but i would like to see it in context with the
> actual replacement kernel.
> 

True. Spoiler: it works as designed. I'm just not yet done with getting
the internals of that linux-custom.inc ready, but switching recipes via
PREFERRED_PROVIDER_virtual/kernel works fine.

> Am Tue, 30 Jan 2018 10:34:45 +0100
> schrieb "Jan Kiszka" <jan.kiszka@siemens.com>:
> 
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This simplifies the common task of using a custom kernel instead of
>> the pre-selected debian variant: Move the kernel installation into a
>> dummy dpkg-raw recipe that only has the kernel package as dependency.
>>
>> Which recipe is used for providing the kernel can now be selected via
>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>
>> The kernel package name is communicated from the target multiconfig
>> file to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>
>> Based on an idea of Henning Schild.
> 
> Really ? I don't remember. 

Yours was at least the idea to use a meta package.

> 
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> Changes in v2:
>>  - install kernel meta package from local repo, instead of trying to
>>    pre-install it from the upstream one
>>    (I swear I tested this and it worked, but I have no idea how it
>>    could...)
>>
>>  meta-isar/conf/multiconfig/qemuamd64-jessie.conf  |  2 +-
>>  meta-isar/conf/multiconfig/qemuamd64-stretch.conf |  3 ++-
>>  meta-isar/conf/multiconfig/qemuarm-jessie.conf    |  2 +-
>>  meta-isar/conf/multiconfig/qemuarm-stretch.conf   |  3 ++-
>>  meta-isar/conf/multiconfig/qemuarm-wheezy.conf    |  2 +-
>>  meta-isar/conf/multiconfig/qemui386-jessie.conf   |  2 +-
>>  meta-isar/conf/multiconfig/qemui386-stretch.conf  |  3 ++-
>>  meta-isar/conf/multiconfig/rpi-jessie.conf        |  3 ++-
>>  meta-isar/recipes-core/images/isar-image-base.bb  |  7 ++++++-
>>  meta-isar/recipes-kernel/linux/linux-debian.bb    | 12 ++++++++++++
>>  10 files changed, 30 insertions(+), 9 deletions(-)
>>  create mode 100644 meta-isar/recipes-kernel/linux/linux-debian.bb
>>
>> diff --git a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
>> b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf index
>> 51d39b6..e49751f 100644 ---
>> a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf +++
>> b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf @@ -6,7 +6,7 @@
>> MACHINE ?= "qemuamd64" DISTRO ?= "debian-jessie"
>>  DISTRO_ARCH ?= "amd64"
>>  
>> -IMAGE_PREINSTALL += "linux-image-amd64"
>> +DEBIAN_KERNEL ?= "linux-image-amd64"
>>  
>>  ROOTFS_DEV ?= "sda"
>>  
>> diff --git a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
>> b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf index
>> c59876a..f3dcd3a 100644 ---
>> a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf +++
>> b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf @@ -8,9 +8,10 @@
>> DISTRO_ARCH ?= "amd64" 
>>  IMAGE_PREINSTALL += " \
>>      init \
>> -    linux-image-amd64 \
>>  "
>>  
>> +DEBIAN_KERNEL ?= "linux-image-amd64"
>> +
>>  ROOTFS_DEV ?= "sda"
>>  
>>  QEMU_ARCH ?= "x86_64"
>> diff --git a/meta-isar/conf/multiconfig/qemuarm-jessie.conf
>> b/meta-isar/conf/multiconfig/qemuarm-jessie.conf index
>> ed84c6c..50a27f5 100644 ---
>> a/meta-isar/conf/multiconfig/qemuarm-jessie.conf +++
>> b/meta-isar/conf/multiconfig/qemuarm-jessie.conf @@ -13,7 +13,7 @@
>> MACHINE ?= "qemuarm" DISTRO ?= "debian-jessie"
>>  DISTRO_ARCH ?= "armhf"
>>  
>> -IMAGE_PREINSTALL += "linux-image-armmp"
>> +DEBIAN_KERNEL ?= "linux-image-armmp"
>>  
>>  ROOTFS_DEV ?= "vda"
>>  
>> diff --git a/meta-isar/conf/multiconfig/qemuarm-stretch.conf
>> b/meta-isar/conf/multiconfig/qemuarm-stretch.conf index
>> 1cce97a..9b99fb0 100644 ---
>> a/meta-isar/conf/multiconfig/qemuarm-stretch.conf +++
>> b/meta-isar/conf/multiconfig/qemuarm-stretch.conf @@ -8,9 +8,10 @@
>> DISTRO_ARCH ?= "armhf" 
>>  IMAGE_PREINSTALL += " \
>>      init \
>> -    linux-image-armmp \
>>  "
>>  
>> +DEBIAN_KERNEL ?= "linux-image-armmp"
>> +
>>  ROOTFS_DEV ?= "vda"
>>  
>>  QEMU_ARCH ?= "arm"
>> diff --git a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
>> b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf index
>> 38ea191..ab163a2 100644 ---
>> a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf +++
>> b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf @@ -13,7 +13,7 @@
>> MACHINE ?= "qemuarm" DISTRO ?= "debian-wheezy"
>>  DISTRO_ARCH ?= "armhf"
>>  
>> -IMAGE_PREINSTALL += "linux-image-vexpress"
>> +DEBIAN_KERNEL ?= "linux-image-vexpress"
>>  
>>  ROOTFS_DEV ?= "mmcblk0"
>>  
>> diff --git a/meta-isar/conf/multiconfig/qemui386-jessie.conf
>> b/meta-isar/conf/multiconfig/qemui386-jessie.conf index
>> d589661..e3df61d 100644 ---
>> a/meta-isar/conf/multiconfig/qemui386-jessie.conf +++
>> b/meta-isar/conf/multiconfig/qemui386-jessie.conf @@ -6,7 +6,7 @@
>> MACHINE ?= "qemui386" DISTRO ?= "debian-jessie"
>>  DISTRO_ARCH ?= "i386"
>>  
>> -IMAGE_PREINSTALL += "linux-image-686-pae"
>> +DEBIAN_KERNEL ?= "linux-image-686-pae"
>>  
>>  ROOTFS_DEV ?= "sda"
>>  
>> diff --git a/meta-isar/conf/multiconfig/qemui386-stretch.conf
>> b/meta-isar/conf/multiconfig/qemui386-stretch.conf index
>> 40239e4..344783e 100644 ---
>> a/meta-isar/conf/multiconfig/qemui386-stretch.conf +++
>> b/meta-isar/conf/multiconfig/qemui386-stretch.conf @@ -8,9 +8,10 @@
>> DISTRO_ARCH ?= "i386" 
>>  IMAGE_PREINSTALL += " \
>>      init \
>> -    linux-image-686-pae \
>>  "
>>  
>> +DEBIAN_KERNEL ?= "linux-image-686-pae"
>> +
>>  ROOTFS_DEV ?= "sda"
>>  
>>  QEMU_ARCH ?= "i386"
>> diff --git a/meta-isar/conf/multiconfig/rpi-jessie.conf
>> b/meta-isar/conf/multiconfig/rpi-jessie.conf index d1dd9d9..cfbeb3a
>> 100644 --- a/meta-isar/conf/multiconfig/rpi-jessie.conf
>> +++ b/meta-isar/conf/multiconfig/rpi-jessie.conf
>> @@ -19,7 +19,6 @@ IMAGE_PREINSTALL += " \
>>      iproute2 \
>>      iputils-ping \
>>      isc-dhcp-client \
>> -    linux-image-rpi-rpfv \
>>      lrzsz \
>>      net-tools \
>>      netcat-openbsd \
>> @@ -31,4 +30,6 @@ IMAGE_PREINSTALL += " \
>>      vim \
>>      "
>>  
>> +DEBIAN_KERNEL ?= "linux-image-rpi-rpfv"
>> +
>>  ROOTFS_DEV ?= "mmcblk0p2"
>> diff --git a/meta-isar/recipes-core/images/isar-image-base.bb
>> b/meta-isar/recipes-core/images/isar-image-base.bb index
>> e359ac3..2f03cd1 100644 ---
>> a/meta-isar/recipes-core/images/isar-image-base.bb +++
>> b/meta-isar/recipes-core/images/isar-image-base.bb @@ -18,12 +18,17
>> @@ PV = "1.0" 
>>  inherit image
>>  
>> -DEPENDS += "${IMAGE_INSTALL}"
>> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-debian"
>> +
>> +DEPENDS += "${IMAGE_INSTALL} \
>> +            virtual/kernel"
>>  
>>  IMAGE_PREINSTALL += "apt \
>>                       dbus \
>>                       localepurge"
>>  
>> +IMAGE_INSTALL += "${@d.getVar("PREFERRED_PROVIDER_virtual/kernel",
>> True)}" +
>>  WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
>>  
>>  do_rootfs[dirs] = "${WORKDIR}/hooks_multistrap"
>> diff --git a/meta-isar/recipes-kernel/linux/linux-debian.bb
>> b/meta-isar/recipes-kernel/linux/linux-debian.bb new file mode 100644
>> index 0000000..21d20c2
>> --- /dev/null
>> +++ b/meta-isar/recipes-kernel/linux/linux-debian.bb
>> @@ -0,0 +1,12 @@
>> +# Debian kernel pseudo package
>> +#
>> +# This software is a part of ISAR.
>> +# Copyright (c) Siemens AG, 2018
>> +
>> +DESCRIPTION = "Prebuilt Debian kernel"
>> +MAINTAINER = "ISAR project"
> 
> Please include an email address here.
> 
> https://www.debian.org/doc/debian-policy/#s-f-maintainer

Pseudo email or the isar mailing list?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2] Install kernel via replaceable recipe

[Alexander Smirnov]

On 01/30/2018 12:34 PM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This simplifies the common task of using a custom kernel instead of the
> pre-selected debian variant: Move the kernel installation into a dummy
> dpkg-raw recipe that only has the kernel package as dependency.
> 
> Which recipe is used for providing the kernel can now be selected via
> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
> 
> The kernel package name is communicated from the target multiconfig file
> to the linux-debian recipe via the DEBIAN_KERNEL variable.

Why it's Debian kernel? This could be a bit confusing, Isar doesn'y 
support only official Debian kernel. For example Isar already supports 
Raspbian which contains its own Raspbian kernel.

> 
> Based on an idea of Henning Schild.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Changes in v2:
>   - install kernel meta package from local repo, instead of trying to
>     pre-install it from the upstream one
>     (I swear I tested this and it worked, but I have no idea how it
>     could...)
> 
>   meta-isar/conf/multiconfig/qemuamd64-jessie.conf  |  2 +-
>   meta-isar/conf/multiconfig/qemuamd64-stretch.conf |  3 ++-
>   meta-isar/conf/multiconfig/qemuarm-jessie.conf    |  2 +-
>   meta-isar/conf/multiconfig/qemuarm-stretch.conf   |  3 ++-
>   meta-isar/conf/multiconfig/qemuarm-wheezy.conf    |  2 +-
>   meta-isar/conf/multiconfig/qemui386-jessie.conf   |  2 +-
>   meta-isar/conf/multiconfig/qemui386-stretch.conf  |  3 ++-
>   meta-isar/conf/multiconfig/rpi-jessie.conf        |  3 ++-
>   meta-isar/recipes-core/images/isar-image-base.bb  |  7 ++++++-
>   meta-isar/recipes-kernel/linux/linux-debian.bb    | 12 ++++++++++++
>   10 files changed, 30 insertions(+), 9 deletions(-)
>   create mode 100644 meta-isar/recipes-kernel/linux/linux-debian.bb
> 
> diff --git a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
> index 51d39b6..e49751f 100644
> --- a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
> +++ b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
> @@ -6,7 +6,7 @@ MACHINE ?= "qemuamd64"
>   DISTRO ?= "debian-jessie"
>   DISTRO_ARCH ?= "amd64"
>   
> -IMAGE_PREINSTALL += "linux-image-amd64"
> +DEBIAN_KERNEL ?= "linux-image-amd64"
>   
>   ROOTFS_DEV ?= "sda"
>   
> diff --git a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
> index c59876a..f3dcd3a 100644
> --- a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
> +++ b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
> @@ -8,9 +8,10 @@ DISTRO_ARCH ?= "amd64"
>   
>   IMAGE_PREINSTALL += " \
>       init \
> -    linux-image-amd64 \
>   "
>   
> +DEBIAN_KERNEL ?= "linux-image-amd64"
> +
>   ROOTFS_DEV ?= "sda"
>   
>   QEMU_ARCH ?= "x86_64"
> diff --git a/meta-isar/conf/multiconfig/qemuarm-jessie.conf b/meta-isar/conf/multiconfig/qemuarm-jessie.conf
> index ed84c6c..50a27f5 100644
> --- a/meta-isar/conf/multiconfig/qemuarm-jessie.conf
> +++ b/meta-isar/conf/multiconfig/qemuarm-jessie.conf
> @@ -13,7 +13,7 @@ MACHINE ?= "qemuarm"
>   DISTRO ?= "debian-jessie"
>   DISTRO_ARCH ?= "armhf"
>   
> -IMAGE_PREINSTALL += "linux-image-armmp"
> +DEBIAN_KERNEL ?= "linux-image-armmp"
>   
>   ROOTFS_DEV ?= "vda"
>   
> diff --git a/meta-isar/conf/multiconfig/qemuarm-stretch.conf b/meta-isar/conf/multiconfig/qemuarm-stretch.conf
> index 1cce97a..9b99fb0 100644
> --- a/meta-isar/conf/multiconfig/qemuarm-stretch.conf
> +++ b/meta-isar/conf/multiconfig/qemuarm-stretch.conf
> @@ -8,9 +8,10 @@ DISTRO_ARCH ?= "armhf"
>   
>   IMAGE_PREINSTALL += " \
>       init \
> -    linux-image-armmp \
>   "
>   
> +DEBIAN_KERNEL ?= "linux-image-armmp"
> +
>   ROOTFS_DEV ?= "vda"
>   
>   QEMU_ARCH ?= "arm"
> diff --git a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
> index 38ea191..ab163a2 100644
> --- a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
> +++ b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
> @@ -13,7 +13,7 @@ MACHINE ?= "qemuarm"
>   DISTRO ?= "debian-wheezy"
>   DISTRO_ARCH ?= "armhf"
>   
> -IMAGE_PREINSTALL += "linux-image-vexpress"
> +DEBIAN_KERNEL ?= "linux-image-vexpress"
>   
>   ROOTFS_DEV ?= "mmcblk0"
>   
> diff --git a/meta-isar/conf/multiconfig/qemui386-jessie.conf b/meta-isar/conf/multiconfig/qemui386-jessie.conf
> index d589661..e3df61d 100644
> --- a/meta-isar/conf/multiconfig/qemui386-jessie.conf
> +++ b/meta-isar/conf/multiconfig/qemui386-jessie.conf
> @@ -6,7 +6,7 @@ MACHINE ?= "qemui386"
>   DISTRO ?= "debian-jessie"
>   DISTRO_ARCH ?= "i386"
>   
> -IMAGE_PREINSTALL += "linux-image-686-pae"
> +DEBIAN_KERNEL ?= "linux-image-686-pae"
>   
>   ROOTFS_DEV ?= "sda"
>   
> diff --git a/meta-isar/conf/multiconfig/qemui386-stretch.conf b/meta-isar/conf/multiconfig/qemui386-stretch.conf
> index 40239e4..344783e 100644
> --- a/meta-isar/conf/multiconfig/qemui386-stretch.conf
> +++ b/meta-isar/conf/multiconfig/qemui386-stretch.conf
> @@ -8,9 +8,10 @@ DISTRO_ARCH ?= "i386"
>   
>   IMAGE_PREINSTALL += " \
>       init \
> -    linux-image-686-pae \
>   "
>   
> +DEBIAN_KERNEL ?= "linux-image-686-pae"
> +
>   ROOTFS_DEV ?= "sda"
>   
>   QEMU_ARCH ?= "i386"
> diff --git a/meta-isar/conf/multiconfig/rpi-jessie.conf b/meta-isar/conf/multiconfig/rpi-jessie.conf
> index d1dd9d9..cfbeb3a 100644
> --- a/meta-isar/conf/multiconfig/rpi-jessie.conf
> +++ b/meta-isar/conf/multiconfig/rpi-jessie.conf
> @@ -19,7 +19,6 @@ IMAGE_PREINSTALL += " \
>       iproute2 \
>       iputils-ping \
>       isc-dhcp-client \
> -    linux-image-rpi-rpfv \
>       lrzsz \
>       net-tools \
>       netcat-openbsd \
> @@ -31,4 +30,6 @@ IMAGE_PREINSTALL += " \
>       vim \
>       "
>   
> +DEBIAN_KERNEL ?= "linux-image-rpi-rpfv"
> +
>   ROOTFS_DEV ?= "mmcblk0p2"
> diff --git a/meta-isar/recipes-core/images/isar-image-base.bb b/meta-isar/recipes-core/images/isar-image-base.bb
> index e359ac3..2f03cd1 100644
> --- a/meta-isar/recipes-core/images/isar-image-base.bb
> +++ b/meta-isar/recipes-core/images/isar-image-base.bb
> @@ -18,12 +18,17 @@ PV = "1.0"
>   
>   inherit image
>   
> -DEPENDS += "${IMAGE_INSTALL}"
> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-debian"
> +
> +DEPENDS += "${IMAGE_INSTALL} \
> +            virtual/kernel"
>   
>   IMAGE_PREINSTALL += "apt \
>                        dbus \
>                        localepurge"
>   
> +IMAGE_INSTALL += "${@d.getVar("PREFERRED_PROVIDER_virtual/kernel", True)}"
> +
>   WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
>   
>   do_rootfs[dirs] = "${WORKDIR}/hooks_multistrap"
> diff --git a/meta-isar/recipes-kernel/linux/linux-debian.bb b/meta-isar/recipes-kernel/linux/linux-debian.bb
> new file mode 100644
> index 0000000..21d20c2
> --- /dev/null
> +++ b/meta-isar/recipes-kernel/linux/linux-debian.bb
> @@ -0,0 +1,12 @@
> +# Debian kernel pseudo package
> +#
> +# This software is a part of ISAR.
> +# Copyright (c) Siemens AG, 2018
> +
> +DESCRIPTION = "Prebuilt Debian kernel"
> +MAINTAINER = "ISAR project"
> +PROVIDES = "virtual/kernel"
> +
> +DEBIAN_DEPENDS = "${DEBIAN_KERNEL}"
> +
> +inherit dpkg-raw

Do I understand correctly, that this recipe creates fake package that 
has dependency from the upstream kernel? So in target rootfs 2 kernel 
packages will be installed?

Alex

Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka]

On 2018-01-30 11:49, Alexander Smirnov wrote:
> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This simplifies the common task of using a custom kernel instead of the
>> pre-selected debian variant: Move the kernel installation into a dummy
>> dpkg-raw recipe that only has the kernel package as dependency.
>>
>> Which recipe is used for providing the kernel can now be selected via
>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>
>> The kernel package name is communicated from the target multiconfig file
>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
> 
> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
> support only official Debian kernel. For example Isar already supports
> Raspbian which contains its own Raspbian kernel.

I'm always open for better name proposals.

> 
>>
>> Based on an idea of Henning Schild.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> Changes in v2:
>>   - install kernel meta package from local repo, instead of trying to
>>     pre-install it from the upstream one
>>     (I swear I tested this and it worked, but I have no idea how it
>>     could...)
>>
>>   meta-isar/conf/multiconfig/qemuamd64-jessie.conf  |  2 +-
>>   meta-isar/conf/multiconfig/qemuamd64-stretch.conf |  3 ++-
>>   meta-isar/conf/multiconfig/qemuarm-jessie.conf    |  2 +-
>>   meta-isar/conf/multiconfig/qemuarm-stretch.conf   |  3 ++-
>>   meta-isar/conf/multiconfig/qemuarm-wheezy.conf    |  2 +-
>>   meta-isar/conf/multiconfig/qemui386-jessie.conf   |  2 +-
>>   meta-isar/conf/multiconfig/qemui386-stretch.conf  |  3 ++-
>>   meta-isar/conf/multiconfig/rpi-jessie.conf        |  3 ++-
>>   meta-isar/recipes-core/images/isar-image-base.bb  |  7 ++++++-
>>   meta-isar/recipes-kernel/linux/linux-debian.bb    | 12 ++++++++++++
>>   10 files changed, 30 insertions(+), 9 deletions(-)
>>   create mode 100644 meta-isar/recipes-kernel/linux/linux-debian.bb
>>
>> diff --git a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
>> b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
>> index 51d39b6..e49751f 100644
>> --- a/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
>> +++ b/meta-isar/conf/multiconfig/qemuamd64-jessie.conf
>> @@ -6,7 +6,7 @@ MACHINE ?= "qemuamd64"
>>   DISTRO ?= "debian-jessie"
>>   DISTRO_ARCH ?= "amd64"
>>   -IMAGE_PREINSTALL += "linux-image-amd64"
>> +DEBIAN_KERNEL ?= "linux-image-amd64"
>>     ROOTFS_DEV ?= "sda"
>>   diff --git a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
>> b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
>> index c59876a..f3dcd3a 100644
>> --- a/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
>> +++ b/meta-isar/conf/multiconfig/qemuamd64-stretch.conf
>> @@ -8,9 +8,10 @@ DISTRO_ARCH ?= "amd64"
>>     IMAGE_PREINSTALL += " \
>>       init \
>> -    linux-image-amd64 \
>>   "
>>   +DEBIAN_KERNEL ?= "linux-image-amd64"
>> +
>>   ROOTFS_DEV ?= "sda"
>>     QEMU_ARCH ?= "x86_64"
>> diff --git a/meta-isar/conf/multiconfig/qemuarm-jessie.conf
>> b/meta-isar/conf/multiconfig/qemuarm-jessie.conf
>> index ed84c6c..50a27f5 100644
>> --- a/meta-isar/conf/multiconfig/qemuarm-jessie.conf
>> +++ b/meta-isar/conf/multiconfig/qemuarm-jessie.conf
>> @@ -13,7 +13,7 @@ MACHINE ?= "qemuarm"
>>   DISTRO ?= "debian-jessie"
>>   DISTRO_ARCH ?= "armhf"
>>   -IMAGE_PREINSTALL += "linux-image-armmp"
>> +DEBIAN_KERNEL ?= "linux-image-armmp"
>>     ROOTFS_DEV ?= "vda"
>>   diff --git a/meta-isar/conf/multiconfig/qemuarm-stretch.conf
>> b/meta-isar/conf/multiconfig/qemuarm-stretch.conf
>> index 1cce97a..9b99fb0 100644
>> --- a/meta-isar/conf/multiconfig/qemuarm-stretch.conf
>> +++ b/meta-isar/conf/multiconfig/qemuarm-stretch.conf
>> @@ -8,9 +8,10 @@ DISTRO_ARCH ?= "armhf"
>>     IMAGE_PREINSTALL += " \
>>       init \
>> -    linux-image-armmp \
>>   "
>>   +DEBIAN_KERNEL ?= "linux-image-armmp"
>> +
>>   ROOTFS_DEV ?= "vda"
>>     QEMU_ARCH ?= "arm"
>> diff --git a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
>> b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
>> index 38ea191..ab163a2 100644
>> --- a/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
>> +++ b/meta-isar/conf/multiconfig/qemuarm-wheezy.conf
>> @@ -13,7 +13,7 @@ MACHINE ?= "qemuarm"
>>   DISTRO ?= "debian-wheezy"
>>   DISTRO_ARCH ?= "armhf"
>>   -IMAGE_PREINSTALL += "linux-image-vexpress"
>> +DEBIAN_KERNEL ?= "linux-image-vexpress"
>>     ROOTFS_DEV ?= "mmcblk0"
>>   diff --git a/meta-isar/conf/multiconfig/qemui386-jessie.conf
>> b/meta-isar/conf/multiconfig/qemui386-jessie.conf
>> index d589661..e3df61d 100644
>> --- a/meta-isar/conf/multiconfig/qemui386-jessie.conf
>> +++ b/meta-isar/conf/multiconfig/qemui386-jessie.conf
>> @@ -6,7 +6,7 @@ MACHINE ?= "qemui386"
>>   DISTRO ?= "debian-jessie"
>>   DISTRO_ARCH ?= "i386"
>>   -IMAGE_PREINSTALL += "linux-image-686-pae"
>> +DEBIAN_KERNEL ?= "linux-image-686-pae"
>>     ROOTFS_DEV ?= "sda"
>>   diff --git a/meta-isar/conf/multiconfig/qemui386-stretch.conf
>> b/meta-isar/conf/multiconfig/qemui386-stretch.conf
>> index 40239e4..344783e 100644
>> --- a/meta-isar/conf/multiconfig/qemui386-stretch.conf
>> +++ b/meta-isar/conf/multiconfig/qemui386-stretch.conf
>> @@ -8,9 +8,10 @@ DISTRO_ARCH ?= "i386"
>>     IMAGE_PREINSTALL += " \
>>       init \
>> -    linux-image-686-pae \
>>   "
>>   +DEBIAN_KERNEL ?= "linux-image-686-pae"
>> +
>>   ROOTFS_DEV ?= "sda"
>>     QEMU_ARCH ?= "i386"
>> diff --git a/meta-isar/conf/multiconfig/rpi-jessie.conf
>> b/meta-isar/conf/multiconfig/rpi-jessie.conf
>> index d1dd9d9..cfbeb3a 100644
>> --- a/meta-isar/conf/multiconfig/rpi-jessie.conf
>> +++ b/meta-isar/conf/multiconfig/rpi-jessie.conf
>> @@ -19,7 +19,6 @@ IMAGE_PREINSTALL += " \
>>       iproute2 \
>>       iputils-ping \
>>       isc-dhcp-client \
>> -    linux-image-rpi-rpfv \
>>       lrzsz \
>>       net-tools \
>>       netcat-openbsd \
>> @@ -31,4 +30,6 @@ IMAGE_PREINSTALL += " \
>>       vim \
>>       "
>>   +DEBIAN_KERNEL ?= "linux-image-rpi-rpfv"
>> +
>>   ROOTFS_DEV ?= "mmcblk0p2"
>> diff --git a/meta-isar/recipes-core/images/isar-image-base.bb
>> b/meta-isar/recipes-core/images/isar-image-base.bb
>> index e359ac3..2f03cd1 100644
>> --- a/meta-isar/recipes-core/images/isar-image-base.bb
>> +++ b/meta-isar/recipes-core/images/isar-image-base.bb
>> @@ -18,12 +18,17 @@ PV = "1.0"
>>     inherit image
>>   -DEPENDS += "${IMAGE_INSTALL}"
>> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-debian"
>> +
>> +DEPENDS += "${IMAGE_INSTALL} \
>> +            virtual/kernel"
>>     IMAGE_PREINSTALL += "apt \
>>                        dbus \
>>                        localepurge"
>>   +IMAGE_INSTALL += "${@d.getVar("PREFERRED_PROVIDER_virtual/kernel",
>> True)}"
>> +
>>   WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
>>     do_rootfs[dirs] = "${WORKDIR}/hooks_multistrap"
>> diff --git a/meta-isar/recipes-kernel/linux/linux-debian.bb
>> b/meta-isar/recipes-kernel/linux/linux-debian.bb
>> new file mode 100644
>> index 0000000..21d20c2
>> --- /dev/null
>> +++ b/meta-isar/recipes-kernel/linux/linux-debian.bb
>> @@ -0,0 +1,12 @@
>> +# Debian kernel pseudo package
>> +#
>> +# This software is a part of ISAR.
>> +# Copyright (c) Siemens AG, 2018
>> +
>> +DESCRIPTION = "Prebuilt Debian kernel"
>> +MAINTAINER = "ISAR project"
>> +PROVIDES = "virtual/kernel"
>> +
>> +DEBIAN_DEPENDS = "${DEBIAN_KERNEL}"
>> +
>> +inherit dpkg-raw
> 
> Do I understand correctly, that this recipe creates fake package that
> has dependency from the upstream kernel? So in target rootfs 2 kernel
> packages will be installed?

Right, one empty linux-debian meta package and the real one. The former
allows us to trivially kick out the latter in favor of a custom kernel.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2] Install kernel via replaceable recipe

[Alexander Smirnov]

On 01/30/2018 01:52 PM, Jan Kiszka wrote:
> On 2018-01-30 11:49, Alexander Smirnov wrote:
>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> This simplifies the common task of using a custom kernel instead of the
>>> pre-selected debian variant: Move the kernel installation into a dummy
>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>
>>> Which recipe is used for providing the kernel can now be selected via
>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>
>>> The kernel package name is communicated from the target multiconfig file
>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>
>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>> support only official Debian kernel. For example Isar already supports
>> Raspbian which contains its own Raspbian kernel.
> 
> I'm always open for better name proposals.

So, if no reasons, I'd propose:
  - KERNEL_PACKAGE
  - KERNEL_PACKAGE_NAME


[...]


>>> +inherit dpkg-raw
>>
>> Do I understand correctly, that this recipe creates fake package that
>> has dependency from the upstream kernel? So in target rootfs 2 kernel
>> packages will be installed?
> 
> Right, one empty linux-debian meta package and the real one. The former
> allows us to trivially kick out the latter in favor of a custom kernel.
> 

What is the benefit of this complexity? If we need to have over-writable 
kernel name, it would be enough to pass current DEBIAN_KERNEL variable 
directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar 
tree and no pseudo package in target rootfs.

Alex

Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka]

On 2018-01-30 12:06, Alexander Smirnov wrote:
> On 01/30/2018 01:52 PM, Jan Kiszka wrote:
>> On 2018-01-30 11:49, Alexander Smirnov wrote:
>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> This simplifies the common task of using a custom kernel instead of the
>>>> pre-selected debian variant: Move the kernel installation into a dummy
>>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>>
>>>> Which recipe is used for providing the kernel can now be selected via
>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>>
>>>> The kernel package name is communicated from the target multiconfig
>>>> file
>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>>
>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>>> support only official Debian kernel. For example Isar already supports
>>> Raspbian which contains its own Raspbian kernel.
>>
>> I'm always open for better name proposals.
> 
> So, if no reasons, I'd propose:
>  - KERNEL_PACKAGE
>  - KERNEL_PACKAGE_NAME
> 
> 
> [...]
> 
> 
>>>> +inherit dpkg-raw
>>>
>>> Do I understand correctly, that this recipe creates fake package that
>>> has dependency from the upstream kernel? So in target rootfs 2 kernel
>>> packages will be installed?
>>
>> Right, one empty linux-debian meta package and the real one. The former
>> allows us to trivially kick out the latter in favor of a custom kernel.
>>
> 
> What is the benefit of this complexity?

It's not complexity, it's simplification and cleanup over the current
hard-coding approach.

> If we need to have over-writable
> kernel name, it would be enough to pass current DEBIAN_KERNEL variable
> directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar
> tree and no pseudo package in target rootfs.

There are several disadvantages with your approach:
- you need to encode the concrete package name instead of just defining
  an abstracting provider
- you need the same thing for linux-headers (which I'm currently very
  interested in as I need to build against the kernel)
- it deviates from the bitbake pattern of PREFERRED_PROVIDER

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2] Install kernel via replaceable recipe

[Alexander Smirnov]

On 01/30/2018 02:25 PM, Jan Kiszka wrote:
> On 2018-01-30 12:06, Alexander Smirnov wrote:
>> On 01/30/2018 01:52 PM, Jan Kiszka wrote:
>>> On 2018-01-30 11:49, Alexander Smirnov wrote:
>>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>
>>>>> This simplifies the common task of using a custom kernel instead of the
>>>>> pre-selected debian variant: Move the kernel installation into a dummy
>>>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>>>
>>>>> Which recipe is used for providing the kernel can now be selected via
>>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>>>
>>>>> The kernel package name is communicated from the target multiconfig
>>>>> file
>>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>>>
>>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>>>> support only official Debian kernel. For example Isar already supports
>>>> Raspbian which contains its own Raspbian kernel.
>>>
>>> I'm always open for better name proposals.
>>
>> So, if no reasons, I'd propose:
>>   - KERNEL_PACKAGE
>>   - KERNEL_PACKAGE_NAME
>>
>>
>> [...]
>>
>>
>>>>> +inherit dpkg-raw
>>>>
>>>> Do I understand correctly, that this recipe creates fake package that
>>>> has dependency from the upstream kernel? So in target rootfs 2 kernel
>>>> packages will be installed?
>>>
>>> Right, one empty linux-debian meta package and the real one. The former
>>> allows us to trivially kick out the latter in favor of a custom kernel.
>>>
>>
>> What is the benefit of this complexity?
> 
> It's not complexity, it's simplification and cleanup over the current
> hard-coding approach.
> 
>> If we need to have over-writable
>> kernel name, it would be enough to pass current DEBIAN_KERNEL variable
>> directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar
>> tree and no pseudo package in target rootfs.
> 
> There are several disadvantages with your approach:
> - you need to encode the concrete package name instead of just defining
>    an abstracting provider

Nothing extra, you already do this in your patch like:

+DEBIAN_KERNEL ?= "linux-image-armmp"

Eventually your abstract provider already contains hardcoded package name.

> - you need the same thing for linux-headers (which I'm currently very
>    interested in as I need to build against the kernel)

This is not clear for me, how headers will be installed from this pseudo 
package. How I could enable/disable headers installation.

> - it deviates from the bitbake pattern of PREFERRED_PROVIDER

For me it doesn't look like preferred_provider pattern. According to the 
bitbake manual:

8<--
Sometimes a target might have multiple providers. A common example is 
"virtual/kernel", which is provided by each kernel recipe. Each machine 
often selects the best kernel provider by using a line similar to the 
following in the machine configuration file:

      PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
8<--

So it's assumed that there are several providers for the same stuff, 
i.e. several *physical* recipes, and in your machine config you select 
the preferred provider, i.e. the name of *physical* recipe.

In current patch there is only one physical provider which contains 
per-machine hardcoded kernel name.

So, none of proposed approaches here (including my one) really 
implements PREFERRED_PROVIDER pattern. To follow it, we need to have 
recipe for each kernel instance.

Alex

Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka]

On 2018-01-30 13:06, Alexander Smirnov wrote:
> On 01/30/2018 02:25 PM, Jan Kiszka wrote:
>> On 2018-01-30 12:06, Alexander Smirnov wrote:
>>> On 01/30/2018 01:52 PM, Jan Kiszka wrote:
>>>> On 2018-01-30 11:49, Alexander Smirnov wrote:
>>>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>
>>>>>> This simplifies the common task of using a custom kernel instead
>>>>>> of the
>>>>>> pre-selected debian variant: Move the kernel installation into a
>>>>>> dummy
>>>>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>>>>
>>>>>> Which recipe is used for providing the kernel can now be selected via
>>>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>>>>
>>>>>> The kernel package name is communicated from the target multiconfig
>>>>>> file
>>>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>>>>
>>>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>>>>> support only official Debian kernel. For example Isar already supports
>>>>> Raspbian which contains its own Raspbian kernel.
>>>>
>>>> I'm always open for better name proposals.
>>>
>>> So, if no reasons, I'd propose:
>>>   - KERNEL_PACKAGE
>>>   - KERNEL_PACKAGE_NAME
>>>
>>>
>>> [...]
>>>
>>>
>>>>>> +inherit dpkg-raw
>>>>>
>>>>> Do I understand correctly, that this recipe creates fake package that
>>>>> has dependency from the upstream kernel? So in target rootfs 2 kernel
>>>>> packages will be installed?
>>>>
>>>> Right, one empty linux-debian meta package and the real one. The former
>>>> allows us to trivially kick out the latter in favor of a custom kernel.
>>>>
>>>
>>> What is the benefit of this complexity?
>>
>> It's not complexity, it's simplification and cleanup over the current
>> hard-coding approach.
>>
>>> If we need to have over-writable
>>> kernel name, it would be enough to pass current DEBIAN_KERNEL variable
>>> directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar
>>> tree and no pseudo package in target rootfs.
>>
>> There are several disadvantages with your approach:
>> - you need to encode the concrete package name instead of just defining
>>    an abstracting provider
> 
> Nothing extra, you already do this in your patch like:
> 
> +DEBIAN_KERNEL ?= "linux-image-armmp"

That defines the distro-specific binary kernel. Ideally, you do not mess
with it as user.

> 
> Eventually your abstract provider already contains hardcoded package name.
> 
>> - you need the same thing for linux-headers (which I'm currently very
>>    interested in as I need to build against the kernel)
> 
> This is not clear for me, how headers will be installed from this pseudo
> package. How I could enable/disable headers installation.

Headers should normally go only into the buildchroot. Basically, the
alternative recipe will take care of providing a different package which
Provides: linux-headers, fill that into the local repo and, thus,
override the upstream package. Not yet tested, I have to admit, but it's
the current plan.

> 
>> - it deviates from the bitbake pattern of PREFERRED_PROVIDER
> 
> For me it doesn't look like preferred_provider pattern. According to the
> bitbake manual:
> 
> 8<--
> Sometimes a target might have multiple providers. A common example is
> "virtual/kernel", which is provided by each kernel recipe. Each machine
> often selects the best kernel provider by using a line similar to the
> following in the machine configuration file:
> 
>      PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
> 8<--
> 
> So it's assumed that there are several providers for the same stuff,
> i.e. several *physical* recipes, and in your machine config you select
> the preferred provider, i.e. the name of *physical* recipe.

Exactly. I have some exemplary linux-mainline_4.14.bb and
linux-cip_4.4.bb here under test. Or you add some linux-hacky-vendor.bb
if needed. Then set the preferred provider accordingly.

> 
> In current patch there is only one physical provider which contains
> per-machine hardcoded kernel name.
> 
> So, none of proposed approaches here (including my one) really
> implements PREFERRED_PROVIDER pattern. To follow it, we need to have
> recipe for each kernel instance.

Stay tuned for having a second user of that feature in-tree soon.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2] Install kernel via replaceable recipe

[Alexander Smirnov]

On 01/30/2018 03:39 PM, Jan Kiszka wrote:
> On 2018-01-30 13:06, Alexander Smirnov wrote:
>> On 01/30/2018 02:25 PM, Jan Kiszka wrote:
>>> On 2018-01-30 12:06, Alexander Smirnov wrote:
>>>> On 01/30/2018 01:52 PM, Jan Kiszka wrote:
>>>>> On 2018-01-30 11:49, Alexander Smirnov wrote:
>>>>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>
>>>>>>> This simplifies the common task of using a custom kernel instead
>>>>>>> of the
>>>>>>> pre-selected debian variant: Move the kernel installation into a
>>>>>>> dummy
>>>>>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>>>>>
>>>>>>> Which recipe is used for providing the kernel can now be selected via
>>>>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>>>>>
>>>>>>> The kernel package name is communicated from the target multiconfig
>>>>>>> file
>>>>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>>>>>
>>>>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>>>>>> support only official Debian kernel. For example Isar already supports
>>>>>> Raspbian which contains its own Raspbian kernel.
>>>>>
>>>>> I'm always open for better name proposals.
>>>>
>>>> So, if no reasons, I'd propose:
>>>>    - KERNEL_PACKAGE
>>>>    - KERNEL_PACKAGE_NAME
>>>>
>>>>
>>>> [...]
>>>>
>>>>
>>>>>>> +inherit dpkg-raw
>>>>>>
>>>>>> Do I understand correctly, that this recipe creates fake package that
>>>>>> has dependency from the upstream kernel? So in target rootfs 2 kernel
>>>>>> packages will be installed?
>>>>>
>>>>> Right, one empty linux-debian meta package and the real one. The former
>>>>> allows us to trivially kick out the latter in favor of a custom kernel.
>>>>>
>>>>
>>>> What is the benefit of this complexity?
>>>
>>> It's not complexity, it's simplification and cleanup over the current
>>> hard-coding approach.
>>>
>>>> If we need to have over-writable
>>>> kernel name, it would be enough to pass current DEBIAN_KERNEL variable
>>>> directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar
>>>> tree and no pseudo package in target rootfs.
>>>
>>> There are several disadvantages with your approach:
>>> - you need to encode the concrete package name instead of just defining
>>>     an abstracting provider
>>
>> Nothing extra, you already do this in your patch like:
>>
>> +DEBIAN_KERNEL ?= "linux-image-armmp"
> 
> That defines the distro-specific binary kernel. Ideally, you do not mess
> with it as user.

My question, why can't you pass this directly to image if you already 
have it hardcoded?

> 
>>
>> Eventually your abstract provider already contains hardcoded package name.
>>
>>> - you need the same thing for linux-headers (which I'm currently very
>>>     interested in as I need to build against the kernel)
>>
>> This is not clear for me, how headers will be installed from this pseudo
>> package. How I could enable/disable headers installation.
> 
> Headers should normally go only into the buildchroot. Basically, the
> alternative recipe will take care of providing a different package which
> Provides: linux-headers, fill that into the local repo and, thus,
> override the upstream package. Not yet tested, I have to admit, but it's
> the current plan.

Ok, it would be interesting.

> 
>>
>>> - it deviates from the bitbake pattern of PREFERRED_PROVIDER
>>
>> For me it doesn't look like preferred_provider pattern. According to the
>> bitbake manual:
>>
>> 8<--
>> Sometimes a target might have multiple providers. A common example is
>> "virtual/kernel", which is provided by each kernel recipe. Each machine
>> often selects the best kernel provider by using a line similar to the
>> following in the machine configuration file:
>>
>>       PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
>> 8<--
>>
>> So it's assumed that there are several providers for the same stuff,
>> i.e. several *physical* recipes, and in your machine config you select
>> the preferred provider, i.e. the name of *physical* recipe.
> 
> Exactly. I have some exemplary linux-mainline_4.14.bb and
> linux-cip_4.4.bb here under test. Or you add some linux-hacky-vendor.bb
> if needed. Then set the preferred provider accordingly.

Yes, I understand this model, it's ok. But this doesn't explain the need 
of pseudo recipe for upstream kernel. It would be more logically correct 
in bitbake philosophy to pass the upstream kernel name directly to 
PREFERRED_PROVIDER:

PREFERRED_PROVIDER_virtual/kernel = "linux-image-armmp"

PREFERRED_PROVIDER_* eventually is passed directly to list of debs to 
install via multistrap, so could shortcut this without pseudo recipe?

> 
>>
>> In current patch there is only one physical provider which contains
>> per-machine hardcoded kernel name.
>>
>> So, none of proposed approaches here (including my one) really
>> implements PREFERRED_PROVIDER pattern. To follow it, we need to have
>> recipe for each kernel instance.
> 
> Stay tuned for having a second user of that feature in-tree soon.
> 

For sure, it would be nice to have it in Isar. :-)

Alex

Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka]

On 2018-01-30 13:57, Alexander Smirnov wrote:
> On 01/30/2018 03:39 PM, Jan Kiszka wrote:
>> On 2018-01-30 13:06, Alexander Smirnov wrote:
>>> On 01/30/2018 02:25 PM, Jan Kiszka wrote:
>>>> On 2018-01-30 12:06, Alexander Smirnov wrote:
>>>>> On 01/30/2018 01:52 PM, Jan Kiszka wrote:
>>>>>> On 2018-01-30 11:49, Alexander Smirnov wrote:
>>>>>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>
>>>>>>>> This simplifies the common task of using a custom kernel instead
>>>>>>>> of the
>>>>>>>> pre-selected debian variant: Move the kernel installation into a
>>>>>>>> dummy
>>>>>>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>>>>>>
>>>>>>>> Which recipe is used for providing the kernel can now be
>>>>>>>> selected via
>>>>>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>>>>>>
>>>>>>>> The kernel package name is communicated from the target multiconfig
>>>>>>>> file
>>>>>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>>>>>>
>>>>>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>>>>>>> support only official Debian kernel. For example Isar already
>>>>>>> supports
>>>>>>> Raspbian which contains its own Raspbian kernel.
>>>>>>
>>>>>> I'm always open for better name proposals.
>>>>>
>>>>> So, if no reasons, I'd propose:
>>>>>    - KERNEL_PACKAGE
>>>>>    - KERNEL_PACKAGE_NAME
>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>>>> +inherit dpkg-raw
>>>>>>>
>>>>>>> Do I understand correctly, that this recipe creates fake package
>>>>>>> that
>>>>>>> has dependency from the upstream kernel? So in target rootfs 2
>>>>>>> kernel
>>>>>>> packages will be installed?
>>>>>>
>>>>>> Right, one empty linux-debian meta package and the real one. The
>>>>>> former
>>>>>> allows us to trivially kick out the latter in favor of a custom
>>>>>> kernel.
>>>>>>
>>>>>
>>>>> What is the benefit of this complexity?
>>>>
>>>> It's not complexity, it's simplification and cleanup over the current
>>>> hard-coding approach.
>>>>
>>>>> If we need to have over-writable
>>>>> kernel name, it would be enough to pass current DEBIAN_KERNEL variable
>>>>> directly to IMAGE_INSTALL. The same result, but no extra recipe in
>>>>> Isar
>>>>> tree and no pseudo package in target rootfs.
>>>>
>>>> There are several disadvantages with your approach:
>>>> - you need to encode the concrete package name instead of just defining
>>>>     an abstracting provider
>>>
>>> Nothing extra, you already do this in your patch like:
>>>
>>> +DEBIAN_KERNEL ?= "linux-image-armmp"
>>
>> That defines the distro-specific binary kernel. Ideally, you do not mess
>> with it as user.
> 
> My question, why can't you pass this directly to image if you already
> have it hardcoded?
> 
>>
>>>
>>> Eventually your abstract provider already contains hardcoded package
>>> name.
>>>
>>>> - you need the same thing for linux-headers (which I'm currently very
>>>>     interested in as I need to build against the kernel)
>>>
>>> This is not clear for me, how headers will be installed from this pseudo
>>> package. How I could enable/disable headers installation.
>>
>> Headers should normally go only into the buildchroot. Basically, the
>> alternative recipe will take care of providing a different package which
>> Provides: linux-headers, fill that into the local repo and, thus,
>> override the upstream package. Not yet tested, I have to admit, but it's
>> the current plan.
> 
> Ok, it would be interesting.
> 
>>
>>>
>>>> - it deviates from the bitbake pattern of PREFERRED_PROVIDER
>>>
>>> For me it doesn't look like preferred_provider pattern. According to the
>>> bitbake manual:
>>>
>>> 8<--
>>> Sometimes a target might have multiple providers. A common example is
>>> "virtual/kernel", which is provided by each kernel recipe. Each machine
>>> often selects the best kernel provider by using a line similar to the
>>> following in the machine configuration file:
>>>
>>>       PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
>>> 8<--
>>>
>>> So it's assumed that there are several providers for the same stuff,
>>> i.e. several *physical* recipes, and in your machine config you select
>>> the preferred provider, i.e. the name of *physical* recipe.
>>
>> Exactly. I have some exemplary linux-mainline_4.14.bb and
>> linux-cip_4.4.bb here under test. Or you add some linux-hacky-vendor.bb
>> if needed. Then set the preferred provider accordingly.
> 
> Yes, I understand this model, it's ok. But this doesn't explain the need
> of pseudo recipe for upstream kernel. It would be more logically correct
> in bitbake philosophy to pass the upstream kernel name directly to
> PREFERRED_PROVIDER:
> 
> PREFERRED_PROVIDER_virtual/kernel = "linux-image-armmp"
> 
> PREFERRED_PROVIDER_* eventually is passed directly to list of debs to
> install via multistrap, so could shortcut this without pseudo recipe?

Then we would need to create a bitbake recipe for each variant of distro
kernels - does not scale. The reason is that PREFERRED_PROVIDER encodes
a recipe, not a debian package.

> 
>>
>>>
>>> In current patch there is only one physical provider which contains
>>> per-machine hardcoded kernel name.
>>>
>>> So, none of proposed approaches here (including my one) really
>>> implements PREFERRED_PROVIDER pattern. To follow it, we need to have
>>> recipe for each kernel instance.
>>
>> Stay tuned for having a second user of that feature in-tree soon.
>>
> 
> For sure, it would be nice to have it in Isar. :-)

It mostly working now, just need to refactor the variables again because
of DISTRO_ARCH != DISTRO_KERNEL_ARCH. The latter is needed in multiple
places. Maybe I will find some time during FOSDEM, otherwise next week.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux