* [PATCH v2] Install kernel via replaceable recipe @ 2018-01-30 9:34 Jan Kiszka 2018-01-30 10:31 ` Henning Schild 2018-01-30 10:49 ` Alexander Smirnov 0 siblings, 2 replies; 11+ messages in thread From: Jan Kiszka @ 2018-01-30 9:34 UTC (permalink / raw) To: isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 9:34 [PATCH v2] Install kernel via replaceable recipe Jan Kiszka @ 2018-01-30 10:31 ` Henning Schild 2018-01-30 10:40 ` Jan Kiszka 2018-01-30 10:49 ` Alexander Smirnov 1 sibling, 1 reply; 11+ messages in thread From: Henning Schild @ 2018-01-30 10:31 UTC (permalink / raw) To: Jan Kiszka; +Cc: isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 10:31 ` Henning Schild @ 2018-01-30 10:40 ` Jan Kiszka 0 siblings, 0 replies; 11+ messages in thread From: Jan Kiszka @ 2018-01-30 10:40 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 9:34 [PATCH v2] Install kernel via replaceable recipe Jan Kiszka 2018-01-30 10:31 ` Henning Schild @ 2018-01-30 10:49 ` Alexander Smirnov 2018-01-30 10:52 ` Jan Kiszka 1 sibling, 1 reply; 11+ messages in thread From: Alexander Smirnov @ 2018-01-30 10:49 UTC (permalink / raw) To: Jan Kiszka, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 10:49 ` Alexander Smirnov @ 2018-01-30 10:52 ` Jan Kiszka 2018-01-30 11:06 ` Alexander Smirnov 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2018-01-30 10:52 UTC (permalink / raw) To: Alexander Smirnov, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 10:52 ` Jan Kiszka @ 2018-01-30 11:06 ` Alexander Smirnov 2018-01-30 11:25 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Alexander Smirnov @ 2018-01-30 11:06 UTC (permalink / raw) To: Jan Kiszka, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 11:06 ` Alexander Smirnov @ 2018-01-30 11:25 ` Jan Kiszka 2018-01-30 12:06 ` Alexander Smirnov 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2018-01-30 11:25 UTC (permalink / raw) To: Alexander Smirnov, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 11:25 ` Jan Kiszka @ 2018-01-30 12:06 ` Alexander Smirnov 2018-01-30 12:39 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Alexander Smirnov @ 2018-01-30 12:06 UTC (permalink / raw) To: Jan Kiszka, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 12:06 ` Alexander Smirnov @ 2018-01-30 12:39 ` Jan Kiszka 2018-01-30 12:57 ` Alexander Smirnov 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2018-01-30 12:39 UTC (permalink / raw) To: Alexander Smirnov, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 12:39 ` Jan Kiszka @ 2018-01-30 12:57 ` Alexander Smirnov 2018-02-01 16:20 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Alexander Smirnov @ 2018-01-30 12:57 UTC (permalink / raw) To: Jan Kiszka, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] Install kernel via replaceable recipe 2018-01-30 12:57 ` Alexander Smirnov @ 2018-02-01 16:20 ` Jan Kiszka 0 siblings, 0 replies; 11+ messages in thread From: Jan Kiszka @ 2018-02-01 16:20 UTC (permalink / raw) To: Alexander Smirnov, isar-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-02-01 16:20 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-30 9:34 [PATCH v2] Install kernel via replaceable recipe Jan Kiszka 2018-01-30 10:31 ` Henning Schild 2018-01-30 10:40 ` Jan Kiszka 2018-01-30 10:49 ` Alexander Smirnov 2018-01-30 10:52 ` Jan Kiszka 2018-01-30 11:06 ` Alexander Smirnov 2018-01-30 11:25 ` Jan Kiszka 2018-01-30 12:06 ` Alexander Smirnov 2018-01-30 12:39 ` Jan Kiszka 2018-01-30 12:57 ` Alexander Smirnov 2018-02-01 16:20 ` Jan Kiszka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox