From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6613620343774904320 X-Received: by 2002:adf:81a1:: with SMTP id 30-v6mr4214648wra.13.1540223306709; Mon, 22 Oct 2018 08:48:26 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:e501:: with SMTP id c1-v6ls160322wmh.15.canary-gmail; Mon, 22 Oct 2018 08:48:26 -0700 (PDT) X-Google-Smtp-Source: ACcGV60lEZKMyG+i6Wfm7HKPPCQxqF6GKqkokeMAQNteEYs8vxgBEfc8odtxdCIuhii/Vd/BRbk7 X-Received: by 2002:a1c:b606:: with SMTP id g6-v6mr1695162wmf.13.1540223306265; Mon, 22 Oct 2018 08:48:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540223306; cv=none; d=google.com; s=arc-20160816; b=kwwD+tnuWkRa8QcWKDSrqor4d/nvpcK54YPBTvZxqprkweYrRSWPdPAMsBptcYr668 dht1A/hR7NjaqlgDRqNInVxSVkjHssLYErLaAu+BXLXvqy2ykqLaDRbpgbIeHGoI8wSW 0TzvEvlxC0YdQNgJ04SeiFaP9ICQLguuC7VpGc2nGhPKGpPUU7ERdprJoMSq0C1yYr+f q/Shqz+/h3qm2G7IGTNKjZOFgAlRhA3dennCorfQbngzZpka6Ud1xvHYghlQQNs6PJcp W7WQPHGtS21NMuqEGecRLo2PkkeOyOAz+W5UmKOpyfFHHk/DAaqv3S2aCRLLXWS8lYxj 9DNQ== 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=Y6v5CO/b8FLfXiLgbDTkPq8KDfZRyC2rklEGekXT9Rk=; b=MmcTVl40MJnQ8SMeDrKE2H9Yk2gSaK+C0hu3Laukvh/9TyV+MR8DQG8R17KM6SheqG Kq7+6JH31IjJjUzlJmTzysxtGpM1tJU4W89Ab3gSTsP2ccAfVcKEC16s7+a28dqFnLzv G4eN8UXDxQQDyMe/3fm1Ryraa1yZH3+tH4jun2TtJvO6mvaRLzpXTo4Ct26s/EU5Jbdj S949zzqkSnaYkvfQ/e8wLbMzxO8HfC43x6qNNNCQDvy0Vit6kpxxIiVhKlKPbHD/io+1 XYpHvDcImW+zBplXwYqReBUNuneF6bYDJp5j1ZVbW1WxQmXzhLhus7wgpF3VzwwCp7AL hWNA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id 202-v6si551174wmo.1.2018.10.22.08.48.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 08:48:26 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id w9MFmOCU008050 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 17:48:24 +0200 Received: from md1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w9MFmMEU004424 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Oct 2018 17:48:24 +0200 Date: Mon, 22 Oct 2018 17:48:44 +0200 From: Henning Schild To: "[ext] Jan Kiszka" Cc: , isar-users Subject: Re: [PATCH] image: include image name in the kernel/initrd image copies Message-ID: <20181022174844.129f366d@md1pvb1c.ad001.siemens.net> In-Reply-To: <695f9e56-13af-9a25-df97-4f1b8a11a364@siemens.com> References: <1539853468-156-1-git-send-email-Cedric_Hombourger@mentor.com> <578d4e7b-292e-3795-08d7-041c9abe80ee@siemens.com> <695f9e56-13af-9a25-df97-4f1b8a11a364@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=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: jpKm7jV0zMUc Am Thu, 18 Oct 2018 12:29:47 +0200 schrieb "[ext] Jan Kiszka" : > On 18.10.18 11:46, chombourger@gmail.com wrote: > >=20 > > Hi Jan, > >=20 > > See below > >=20 > > On Thursday, October 18, 2018 at 11:27:10 AM UTC+2, Jan Kiszka > > wrote: > >=20 > > On 18.10.18 11:04, Cedric Hombourger wrote: =20 > > > The kernel and initrd images are really image-specific > > > (especially the later with the initrd being created/updated > > > as packages get installed into the =20 > > root =20 > > > file-system). Make sure we retain a per-image copy of these > > > images in the =20 > >=20 > > I don't buy this argument yet: Which additional parameters > > besides the and the MACHINE make kernel different? > >=20 > >=20 > > An image recipe may pull a different kernel than the default kernel > > proposed by the MACHINE or DISTRO > > There are several ways: locally setting KERNEL_NAME, > > IMAGE_INSTALL_remove games, etc. > >=20 > > This is obviously a less frequent use-case than the initrd which is > > evidently populated based on hooks/scripts installed into your root > > file-system (and therefore image dependent) =20 >=20 > OK, in that light, it is something that should be called just like > the generated image. But I think the whole beast needs rework now. > See below. >=20 > >=20 > > If there is any, can't we associate that > > variation more directly with the image then? It's surely not > > the image recipe name. > >=20 > >=20 > > Would you have a suggestion (based on the extra info I provided > > above)? > >=20 > > A possibly cleaner solution would be to NOT copy these files=20 > > into=C2=A0DEPLOY_DIR_IMAGE in the first place! and have e.g. wic plugins > > extract the kernel/initrd images from the rootfs they are working > > with I am happy to rework this patch if breaking the API (by > > removing KERNEL_IMAGE and INITRD_IMAGE) is an option =20 >=20 > We have two use cases so far: QEMU and wic. Both work without > downstream effort by just using those two variables. That by itself > is not bad. An alternative might only by peeking directly into the > rootfs trees of the images, i.e. avoiding the copying to deploy. Not > sure, actually, what value this copy-out provides, at least as long > as the user does not manual deployment of the artifacts. I think the only reason may be qemus --kernel and --initrd. Wic could probably deal with the kernel being inside the rootfs, in the wic case we even "ship" the files twice because /boot/ never gets cleaned. But qemu is not able to look into an ext4img and the deploydir is the only safe place to keep results. If qemu is indeed the only reason, we should get rid of the copy and change the ci-scripts to extract the ext4 for a temporary copy. Henning > Anyway. If we keep copy-out: Instead of appending further elements to > the kernel/initrd prefix, we should really consolidate things. The > image, maybe it be wic-generated or ext4-img or whatever, as well as > associated artifacts should follow the same file naming scheme so > that you can easily identify related artifacts. >=20 > Furthermore, we likely need to update things like=20 > do_copy_boot_files[stamp-extra-info], > do_populate_sdk[stamp-extra-info] to follow those patterns as well. >=20 > Jan >=20