From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7003689951757860864 X-Received: by 2002:a2e:730b:: with SMTP id o11mr13929685ljc.176.1631001611503; Tue, 07 Sep 2021 01:00:11 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:597:: with SMTP id 145ls1484352ljf.7.gmail; Tue, 07 Sep 2021 01:00:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKVMfalsXc10y83HUrlhZ3Syr78BnF3uWB7C7vFsXbbQykT7QfJelz1G3P94RDf70I7Sou X-Received: by 2002:a2e:7d13:: with SMTP id y19mr6657871ljc.344.1631001610364; Tue, 07 Sep 2021 01:00:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631001610; cv=none; d=google.com; s=arc-20160816; b=B4HUOVodRha1PK285LEy1U8BL7iS8lHv/WrQZvC1q/oAjTcG3Vq4DBDithnjZq4jYf TWAZ81l2x5J8NOfPSicbBAI7d0dvo67Gfdhs+YN2gji8eNv9o+tAlhv0/ETJqikAy239 sIpqE2zJA3Yjyqr8TL3W4CuQFEolCfl+iPii+A2xOFczI4zVk4qXQnHCCRvFwseH5d/B sTurdnJWcKLUha1k7kBn2Z6PjuXbf6Fa51onjvHX5wM20QiRdID0UFbgDzQNX/QQDx53 qsFH++LrzX+6DMyL5qXbWwq344IAfVQDSb2dtwye/10MbxU2f6IhUUHPgzH1gN3oDqz1 hiAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=m2W/CDzW/I5TqWbNuz4oEnbQRSZGlnFgIfcyfwOGvuw=; b=mSzNo4qNvX9eDme8D4pgg18IIMQ4MrlYVM5Vc6pQ21wvuSSXdkQBCrsITgZONAPsHS gTQb/fh5177jCMrk9Zmv9y0ghHEN8pX88pVVteWGHDYxmQxo+23p7hDjvt4Z5sDXHEcL 69knuwyRqTCbpr1WXAFdyGlUiIoTuzt51Y+5J5VadZpELR0Y23sgBALXsM3JGOkP0GZj KhVmH6EKPBQ/ufw3eKpXkglxTOjjcdvY7zDImyVliWxFZiYDDnTcgCJpm8j5dbX8lMBC w3uTOVPWDOoXMcdhlz4schCQVElrJHrRXUbKEa/BN1dXZE92XdnJmVaBek2rMIOqVnUM raZQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id o22si189971lfu.4.2021.09.07.01.00.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Sep 2021 01:00:10 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 187809Z7028619 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Sep 2021 10:00:09 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.0.106]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 187809vi022314; Tue, 7 Sep 2021 10:00:09 +0200 Date: Tue, 7 Sep 2021 10:00:09 +0200 From: Henning Schild To: "Bezdeka, Florian (T RDA IOT SES-DE)" Cc: "isar-users@googlegroups.com" , "Kiszka, Jan (T RDA IOT)" , "Vijaikumar_Kanagarajan@mentor.com" Subject: Re: [PATCH v2 0/7] re-fork wic pcbios and efi plugins Message-ID: <20210907100009.4c6c4ee1@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20210903125355.12279-1-henning.schild@siemens.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: e9xAWiJiY0n7 Am Tue, 7 Sep 2021 09:15:36 +0200 schrieb "Bezdeka, Florian (T RDA IOT SES-DE)" : > On Fri, 2021-09-03 at 14:53 +0200, Henning Schild wrote: > > changes since v1: > > - efi plugin forked as well > > - systemd-boot support in efi plugin enabled > > - common functionality in utility library > > - test case for system-boot > > - "cp -a" moved to "find exec cp" because of ubuntu > > - changed wks files to exclude boot from root and mount it > > > > The forked plugins have gotten out of sync with the last wic version > > bumps. And the original fork was not exactly minimal or made for > > easy maintenance. > > > > This series does a re-fork of the two plugins with the aim to come > > up with something readable, minimal and maintainable. > > > > There used to be a special case for grub-efi where the actual > > kernel and initrd would remain in the root partition, which kind of > > allowed kernel updates with apt-get. Now all three bootloaders > > (systemd-boot now works as well) place bootloader, config and boot > > artifacts in a boot-partition. > > > > Kernel updates with apt-get are now consistantly "broken". That > > consistency very likely is not too bad. A generic solution for this > > feature (if wanted) will need to be found. Covering not just these > > three bootloaders but possibly also u-boot and efibootguard. > > I had a quick look and asked myself if it would be possible to > implement the ISAR specific parts in sub-classes of such plugins. I > assume that would require some upstream work first, followed by a re- > sync and adding the ISAR stuff in plugins that inherit from the > upstream ones. My original goal was in fact to reduce it to only bits that can be upstreamed. In general we need to hook into generation of the config, because we use another name for that kernel binary and because we use an initrd. After that the installation of the binaries differs mainly in where they come from. That looks really simple for systemd-boot, a little more involved for syslinux and really very different for grub. In addition the population of boot with kernel initrd and misc files differs in isar. I would not easily find a way to make that generic enough to try and motivate OE to change those classes to be "more generic". It is in bits just pretty different. > As far as I can see all affected plugins are python classes. I'm not a > python expert but I guess that should be doable and would completely > isolate the ISAR parts from the upstream stuff. Yes an no. Once forked they are only there to serve isar. Any kind of "monkey patching" would likely require more code and still be patching/forking. If even possible i would not know how. As we can see in this series, a regular fork inherits useful bits from the original. I was really surprised how easy it was to enable systemd-boot. And i tend to prefer that over grub, because the bootloader is installed from the rootfs and not buildchroot ... and is therefore also part of the Bill Of Materials. But yes, such a plugin just needs to implement the interface of such a class. But it seems like deriving from the original results in way less isar-specific code. In fact we do have a fork of "bootimg-biosplusefi" in one of our layers, that one is only about very little renaming. Basically calling the efi and the pcbios plugins. That very likely only works so well because our plugins are forked and so very similar. I have nothing against further improvements in the future. But as it stands this series remains with "forking" but doing so in a hopefully easier to maintain way. And it aligns our forks with the originals. IMHO that is worth merging and whether further steps will be needed in the future remains to be seen. The upstream classes do not change too often and not too dramatic. So the biggest risk in isar is lack of disciple/care when bumping wic and low test coverage. Both points that we might want to improve. We have the suggestion from Jan to write a documents where we list "forked" bits, and i have a bunch more patches to increase test coverage. i.e. arm64 efi booting https://github.com/henning-schild-work/isar/tree/henning/staging9 regards, Henning > > > > Henning Schild (7): > > wic: reset our plugin forks to OE upstream for re-forking > > wic: add utility library for common bits of isar plugins > > wic: apply the actual fork changes to our pcbios plugin fork > > wic: clean up wic class in terms of isar variables > > wic: apply the actual fork changes to our efi plugin fork > > wic: mount /boot and exlude it from root for efi > > meta-isar: use "systemd-boot" for one test target > > > > RECIPE-API-CHANGELOG.md | 9 + > > meta-isar/conf/machine/qemuamd64.conf | 3 + > > .../scripts/lib/wic/canned-wks/hikey.wks | 4 +- > > .../lib/wic/canned-wks/sdimage-efi-sd.wks | 9 + > > .../lib/wic/canned-wks/sdimage-efi.wks | 4 +- > > meta/classes/wic-img.bbclass | 6 +- > > .../scripts/lib/wic/plugins/isarpluginbase.py | 39 ++++ > > .../wic/plugins/source/bootimg-efi-isar.py | 200 > > ++++++++++++++---- .../wic/plugins/source/bootimg-pcbios-isar.py | > > 139 ++++++------ 9 files changed, 290 insertions(+), 123 > > deletions(-) create mode 100644 > > meta-isar/scripts/lib/wic/canned-wks/sdimage-efi-sd.wks create mode > > 100644 meta/scripts/lib/wic/plugins/isarpluginbase.py >