From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6651523578180141056 X-Received: by 2002:a1c:4183:: with SMTP id o125mr279031wma.24.1548753052802; Tue, 29 Jan 2019 01:10:52 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a7b:ce8d:: with SMTP id q13ls2272655wmj.12.canary-gmail; Tue, 29 Jan 2019 01:10:52 -0800 (PST) X-Google-Smtp-Source: AHgI3IZtKsHSfI+lcq5XE1w0ykZksqP1ziulZRdDgDeGkUlMeZUcGOFXETvnbz5AGpc58tcSrN8M X-Received: by 2002:a7b:c414:: with SMTP id k20mr266148wmi.8.1548753051989; Tue, 29 Jan 2019 01:10:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548753051; cv=none; d=google.com; s=arc-20160816; b=TqueK7iXhxAhhUPUtc3ap6YFcyPagabfChcNzVkUExXJMic4WY7IX0co9jX0lshlY7 GoLOxZWpLaDaPAgj/Dj4pUre9c7/fpNx25bs50keS9x5EyrwZTQOXU0QWKEIU1EsuHWn 2roYrvO4MIPzf/7AJUeBJOg+ad5ObjuzIdLVAPkT6vL1sTugTSUrFGpqmaGiQiOlta6b yEqNueUIJb4znAvII2RNQ0TOHYHq6scNv9OWhkqrySEs+2b5bhRFVBv8QPAHLceqHvgj ZDOY0VoSsdpwo4u+9VisQmIEkV39c9+0LUU6RUOtm8bysC1m3JDufCN/oJRqNefhMtwW p0JQ== 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=YpnG+/HdGqMYimecD80v/Xbvc+T2Y5J3mNKGf/tcZMU=; b=tp2uTEaFasMFkX7YyAnBLJ6u+y+R7DjzxB0DSGIBETXrlMzfyEM/soZoOntYmVdtuO XiF+e0voDBhqBMenCaplar1JfeOZu+7i2Hy3gjN9i1eETARfKguNOvpS5a0N1r4Ym6FZ TXdQxQwbi48uGGvLPOjTZ6SHTn/aSe0GzikKTWJgFvpempZrXkSW9hSOVD8AcaM/QrJt PZDx3gUTnZ0yi6oewJq2HqI2F+yYQWXVoox5uZvvxklscgN2f/njQ9Dk/czoT2xHpFoO RjN9Ul5vnJNa/yxB64J3UUifAV4wqB8YDqpPkz3h9PAykQ22gtR11Up7tw9QciMtMvwQ kvQg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id q63si76600wme.2.2019.01.29.01.10.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 01:10:51 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x0T9ApXe030523 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Jan 2019 10:10:51 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.0.30]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x0T9AoxG032169; Tue, 29 Jan 2019 10:10:50 +0100 Date: Tue, 29 Jan 2019 10:10:50 +0100 From: Henning Schild To: Claudius Heine Cc: , Claudius Heine Subject: Re: [PATCH 2/2] integrate ubifs image type Message-ID: <20190129101050.7681afdc@md1za8fc.ad001.siemens.net> In-Reply-To: <5fab2f59-9f15-713f-f2c8-15886800a3dc@siemens.com> References: <20190128122821.10002-1-claudius.heine.ext@siemens.com> <20190128122821.10002-3-claudius.heine.ext@siemens.com> <20190128140344.7bc5f072@md1za8fc.ad001.siemens.net> <20190128182237.04ab656b@md1za8fc.ad001.siemens.net> <5fab2f59-9f15-713f-f2c8-15886800a3dc@siemens.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: GepZeAOBbGyK On Tue, 29 Jan 2019 09:16:02 +0100 Claudius Heine wrote: > Hi Henning, > > On 28/01/2019 18.22, Henning Schild wrote: > > Am Mon, 28 Jan 2019 14:40:36 +0100 > > schrieb Claudius Heine : > > > >> Hi Henning, > >> > >> On 28/01/2019 14.03, Henning Schild wrote: > >>> Am Mon, 28 Jan 2019 13:28:21 +0100 > >>> schrieb "[ext] claudius.heine.ext@siemens.com" > >>> : > >>> > >>>> From: Claudius Heine > >>>> > >>>> Signed-off-by: Claudius Heine > >>>> --- > >>>> doc/user_manual.md | 1 + > >>>> meta-isar/conf/local.conf.sample | 1 + > >>>> .../multiconfig/qemuamd64-buster-ubifs.conf | 16 +++++++ > >>>> meta/classes/ubifs-img.bbclass | 42 > >>>> +++++++++++++++++++ > >>>> scripts/ci_build.sh | 1 + 5 files > >>>> changed, 61 insertions(+) create mode 100644 > >>>> meta-isar/conf/multiconfig/qemuamd64-buster-ubifs.conf create > >>>> mode 100644 meta/classes/ubifs-img.bbclass > >>>> > >>>> diff --git a/doc/user_manual.md b/doc/user_manual.md > >>>> index c4fe42a..c9924ad 100644 > >>>> --- a/doc/user_manual.md > >>>> +++ b/doc/user_manual.md > >>>> @@ -476,6 +476,7 @@ Isar contains additional image type classes > >>>> that can be used as reference: > >>>> - `ext4-img` > >>>> - `rpi-sdimg` > >>>> - `targz-img` > >>>> + - `ubifs-img` > >>>> - `wic-img` > >>>> > >>>> --- > >>>> diff --git a/meta-isar/conf/local.conf.sample > >>>> b/meta-isar/conf/local.conf.sample index a671b20..9ea366c 100644 > >>>> --- a/meta-isar/conf/local.conf.sample > >>>> +++ b/meta-isar/conf/local.conf.sample > >>>> @@ -53,6 +53,7 @@ BBMULTICONFIG = " \ > >>>> hikey-stretch \ > >>>> qemuamd64-buster \ > >>>> qemuamd64-buster-tgz \ > >>>> + qemuamd64-buster-ubifs \ > >>>> rpi-jessie \ > >>>> " > >>>> > >>>> diff --git > >>>> a/meta-isar/conf/multiconfig/qemuamd64-buster-ubifs.conf > >>>> b/meta-isar/conf/multiconfig/qemuamd64-buster-ubifs.conf new > >>>> file mode 100644 index 0000000..7c638b9 --- /dev/null > >>>> +++ b/meta-isar/conf/multiconfig/qemuamd64-buster-ubifs.conf > >>>> @@ -0,0 +1,16 @@ > >>>> +# This software is a part of ISAR. > >>>> +# Copyright (c) Siemens AG, 2018 > >>>> +# > >>>> +# SPDX-License-Identifier: MIT > >>>> + > >>>> +MACHINE ?= "qemuamd64" > >>>> + > >>>> +DISTRO ?= "debian-buster" > >>>> +DISTRO_ARCH ?= "amd64" > >>>> + > >>>> +KERNEL_NAME ?= "amd64" > >>>> + > >>>> +MKUBIFS_ARGS ?= "-m 0x1000 -e 0x3e000 -c 1500" > >>>> +IMAGE_TYPE ?= "ubifs-img" > >>>> + > >>>> +IMAGE_INSTALL += "sshd-regen-keys" > >>>> diff --git a/meta/classes/ubifs-img.bbclass > >>>> b/meta/classes/ubifs-img.bbclass new file mode 100644 > >>>> index 0000000..f5e17d3 > >>>> --- /dev/null > >>>> +++ b/meta/classes/ubifs-img.bbclass > >>>> @@ -0,0 +1,42 @@ > >>>> +# This software is a part of ISAR. > >>>> +# Copyright (c) Siemens AG, 2018 > >>>> + > >>>> +python() { > >>>> + if not d.getVar("MKUBIFS_ARGS"): > >>>> + bb.fatal("MKUBIFS_ARGS must be set") > >>>> +} > >>>> + > >>>> +inherit image > >>> > >>> I dislike all this variable setting and additional mounting. > >>> > >>>> +UBIFS_IMAGE_FILE ?= "${IMAGE_FULLNAME}.ubifs.img" > >>>> + > >>>> +IMAGER_INSTALL += "mtd-utils" > >>>> + > >>>> +PP = "/home/builder/${PN}" > >>> > >>> That is already defined in another file in Isar. We should rather > >>> find a common location and refactor. > >>> > >>>> +PP_DEPLOY = "${PP}/deploy" > >>>> +PP_ROOTFS = "${PP}/rootfs" > >>> > >>> Similar comments might apply here. > >> > >> Do you think that refactoring should be part of this patchset? > > > > I am not sure, just wanted to write it down. On the one hand it > > would be nice to solve all drive-by issues as we go. On the other > > hand that will slow down development and impose on contributors. > > So feel free to ignore my comments, the inconsistencies are not your > > fault and asking you to fix them would be too much. > > Maybe we should open issues for all those inconsistencies and > annoyances, so that they can be fixed or at least be documented. We do not use issues, so we would need another way to track not fully resolved discussions from the list. But i agree, it would be nice to keep track of things in a structured way to fix them eventually. Maybe a TODO.md? > At some point making a complete code review (not just patches) on > isar would be great, just to find and fix those. I thought the same, maybe an Isar hackathon. > >>>> +BUILDROOT = "${BUILDCHROOT_DIR}${PP}" > >>>> +BUILDROOT_DEPLOY = "${BUILDCHROOT_DIR}${PP_DEPLOY}" > >>>> +BUILDROOT_ROOTFS = "${BUILDCHROOT_DIR}${PP_ROOTFS}" > >>> > >>> Same here, and "buildroot" to me is something else ;). > >> > >> That is part of my plot to slowly merge bitbake, isar and > >> buildroot ;) > > > > Good first step. We actually have buildroot isar recipes in > > jailhouse-images, so this name can potentially get confusing for > > real. > > I took this variable name from: > > https://github.com/ilbers/isar/blob/22f2387b3791a1c6c88b8c4424285d7788c3743c/meta/classes/dpkg-base.bbclass#L49 > > So fixing this should be done as well then? I guess in that case the name is OK. Henning > > > >>> > >>>> +do_ubifs_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" > >>>> + > >>>> +# Generate ubifs filesystem image > >>>> +do_ubifs_image() { > >>>> + rm -f ${DEPLOY_DIR_IMAGE}/${UBIFS_IMAGE_FILE} > >>>> + > >>>> + buildchroot_do_mounts > >>>> + > >>>> + sudo flock ${MOUNT_LOCKFILE} -c ' \ > >>>> + mkdir -p ${BUILDROOT_DEPLOY} ${BUILDROOT_ROOTFS} > >>>> + mount --bind ${DEPLOY_DIR_IMAGE} ${BUILDROOT_DEPLOY} > >>>> + mount --bind ${IMAGE_ROOTFS} ${BUILDROOT_ROOTFS} > >>>> + ' > >>> > >>> I think this mounting should also be required by a proper ext4 > >>> class. On the other hand the wic one moves the image into the > >>> final deploy folder. > >>> Not sure what is best but maybe a good idea to go for "always > >>> move" or "always mount". > >> > >> Hmm.. In OE this task would not to touch the deploy directory and > >> *copy* all artifacts in a dedicated task AFAIK. But OE has a > >> completely different image creation pipeline and infrastructure > >> than isar, so who knows how things should be done here. > > > > We currently generate and deploy in one task. The fun thing is that > > we need multiple commands and can probably end up in weird states > > if we get interrupted or fail. > > > > Changing that general pattern is a discussion of its own, since it > > would change the API. > > > > Staying in the current API i think the mount and generate directly > > into deploy ... no more chmod/chown mv ... whatever. Would be the > > cleanest way. We already have a reliable umount mechanism to clean > > up if things go wrong. > > > > If you agree: Please include that deploydir/rootfs mount into the > > common mounts and update your imager. I will do the same for wic > > and maybe ext4. > > Ok. Will do that. > > > > >> I am open to discussion about implementing some rules and > >> documentation about how things should be done in isar. > > > > I assume that consistent references are equally efficient as > > documentation, maybe more. > > Right! > > Cheers, > Claudius > > > > > Henning > > > >> Claudius > >> > >>> > >>> Henning > >>> > >>>> + # Create ubifs image using buildchroot tools > >>>> + sudo chroot ${BUILDCHROOT_DIR} /usr/sbin/mkfs.ubifs > >>>> ${MKUBIFS_ARGS} \ > >>>> + -r "${PP_ROOTFS}" > >>>> "${PP_DEPLOY}/${UBIFS_IMAGE_FILE}" +} > >>>> + > >>>> +addtask ubifs_image before do_build after do_copy_boot_files > >>>> do_install_imager_deps diff --git a/scripts/ci_build.sh > >>>> b/scripts/ci_build.sh index f3523e8..dcde0b4 100755 > >>>> --- a/scripts/ci_build.sh > >>>> +++ b/scripts/ci_build.sh > >>>> @@ -115,6 +115,7 @@ else > >>>> multiconfig:qemuamd64-stretch:isar-image-base \ > >>>> multiconfig:qemuamd64-buster:isar-image-base \ > >>>> multiconfig:qemuamd64-buster-tgz:isar-image-base \ > >>>> + multiconfig:qemuamd64-buster-ubifs:isar-image-base \ > >>>> multiconfig:rpi-jessie:isar-image-base > >>>> # qemu-user-static of <= buster too old to build that > >>>> #multiconfig:qemuarm64-buster:isar-image-base > >>> > >> > > >