Re: [isar-cip-core][PATCH v4 2/8] refactor: use imagetypes for swu generation

[Jan Kiszka <jan.kiszka@siemens.com>]

On 14.02.23 03:10, Moessbauer, Felix (T CED INW-CN) wrote:
> On Mon, 2023-02-13 at 16:28 +0100, Jan Kiszka wrote:
>> On 12.02.23 09:27, Felix Moessbauer wrote:
>>> This patch reworks the implementation of the swupdate type.
>>> All generic aspects are moved from the swupdate.inc file into the
>>> swupdate class and made conditional on the swu type.
>>> The sw-description file is now referenced using the image-type
>>> infrastructure, which avoids manual additions to FILESEXTRAPATHS
>>> and
>>> accidental overwrites of SRC_URI. The templating logic is moved
>>> into the
>>> generic one provided by imagetypes.
>>>
>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>> ---
>>>  classes/swupdate.bbclass                      | 26 ++++++++++++---
>>> ----
>>>  kas/opt/swupdate.yml                          |  5 +---
>>>  .../images/{files => swu}/sw-description.tmpl |  0
>>>  recipes-core/images/swupdate.inc              | 15 -----------
>>>  4 files changed, 18 insertions(+), 28 deletions(-)
>>>  rename recipes-core/images/{files => swu}/sw-description.tmpl
>>> (100%)
>>>
>>> diff --git a/classes/swupdate.bbclass b/classes/swupdate.bbclass
>>> index 5eb4936..966f7c0 100644
>>> --- a/classes/swupdate.bbclass
>>> +++ b/classes/swupdate.bbclass
>>> @@ -8,23 +8,33 @@
>>>  #  Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>>  #
>>>  # SPDX-License-Identifier: MIT
>>> +ROOTFS_PARTITION_NAME ?= "${IMAGE_FULLNAME}.wic.p4.gz"
>>>
>>>  SWU_IMAGE_FILE ?= "${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-
>>> ${MACHINE}.swu"
>>>  SWU_DESCRIPTION_FILE ?= "sw-description"
>>> -SWU_ADDITIONAL_FILES ?= ""
>>> +SWU_ADDITIONAL_FILES ?= "linux.efi ${ROOTFS_PARTITION_NAME}"
>>>  SWU_SIGNED ?= ""
>>>  SWU_SIGNATURE_EXT ?= "sig"
>>>  SWU_SIGNATURE_TYPE ?= "rsa"
>>>
>>>  BUILDCHROOT_IMAGE_FILE ?=
>>> "${PP_DEPLOY}/${@os.path.basename(d.getVar('SWU_IMAGE_FILE'))}"
>>>
>>> -IMAGER_INSTALL += "cpio"
>>> -IMAGER_INSTALL += "${@'openssl' if
>>> bb.utils.to_boolean(d.getVar('SWU_SIGNED')) else ''}"
>>> +IMAGE_TYPEDEP:wic += "squashfs"
>>> +IMAGE_TYPEDEP:swu = "wic"
>>> +IMAGER_INSTALL:swu += "cpio ${@'openssl' if
>>> bb.utils.to_boolean(d.getVar('SWU_SIGNED')) else ''}"
>>>
>>> -do_swupdate_binary[stamp-extra-info] = "${DISTRO}-${MACHINE}"
>>> -do_swupdate_binary[cleandirs] += "${WORKDIR}/swu"
>>> -do_swupdate_binary[network] = "${TASK_USE_SUDO}"
>>> -do_swupdate_binary() {
>>> +IMAGE_SRC_URI:swu = "file://${SWU_DESCRIPTION_FILE}.tmpl"
>>> +IMAGE_TEMPLATE_FILES:swu = "${SWU_DESCRIPTION_FILE}.tmpl"
>>> +IMAGE_TEMPLATE_VARS:swu = "ROOTFS_PARTITION_NAME TARGET_IMAGE_UUID
>>> ABROOTFS_PART_UUID_A ABROOTFS_PART_UUID_B"
>>> +
>>> +# This imagetype is neither machine nor distro specific. Hence, we
>>> cannot
>>> +# use paths in FILESOVERRIDES. Manual modifications of this
>>> variable are
>>> +# discouradged and hard to implement. Instead, we register this
>>> path explicitly
>>> +FILESEXTRAPATHS:prepend = "${LAYERDIR_cip-core}/recipes-
>>> core/images/swu:"
>>
>> This means downstream layers wanting to overload the sw-
>> description.tmpl
>> now need to register their own FILESEXTRAPATHS? That at least
>> requires
>> documentation. Or can we also drop LAYERDIR_cip-core here, and it
>> would
>> still work?
> 
> That is exactly as it always has been. But downstream layer have to add
> it only if they override the SWU_DESCRIPTION_FILE. IMHO this is
> reasonable. I highly vote for keeping it like that, as these kind of
> things bite us again and again with each bitbake update.
> 

If I write

[my-image.bb]
inherit swupdate

and place an own sw-description.tmpl in my own files/ folder, will that
be picked (as to be naturally expected) or the one from cip-core?

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux