From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6613620343774904320 X-Received: by 2002:a17:906:8695:: with SMTP id g21-v6mr5836543ejx.4.1539858590217; Thu, 18 Oct 2018 03:29:50 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:a383:: with SMTP id k3-v6ls6623877ejz.14.gmail; Thu, 18 Oct 2018 03:29:49 -0700 (PDT) X-Google-Smtp-Source: ACcGV62aQTYfOKLubUGWxrtzocbYgE+v8z80JNA7SBs1EHKbMKbVdjBt6lh5mm7tm86d8wOPN0Pj X-Received: by 2002:a17:906:8695:: with SMTP id g21-v6mr5836536ejx.4.1539858589739; Thu, 18 Oct 2018 03:29:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539858589; cv=none; d=google.com; s=arc-20160816; b=RB1KRon8QBm4qqqJcspodeq4AnZ5Xyzf3Q+z9rS2fzkFF7JfG5w37tQVFfQuT8Okwi hsELT1Kg8A8ewM87xsLuZU8fGQAQ4oiq80lQlmLvLzImOQyPHmQwaztL9M6pu/H4jYA/ 39CQxS9xeKnjmqnUik+uOmrzirvwuTjgQqu6urkHdZQcKVO3lbhCFtTfJwvsDQi3asx/ Uh1jeByrV3koFFnyhIiihg40TkuXiPa2/tebHrwsr2UJSHCH2iwrQQ/yyeiHT0xmzQlF KUDU6d6fPvuf0CWMn9Lxr/xFXhUZ70t/0wBqHpdybW0gLtAaaplFxahwMvEdsCVIjPjT f/xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=FplvoqcsCcokpOD83CsM3fbox4EHXhAhPTeOwwrDUdQ=; b=ngVDCPbM00PZulsgl8dikLKGJ+1XvPJhrTNq786BdYHUNbMzyljrGDdKG7+s1//Q3H mdpKG+AaOPgklrlSHiZ7FMw8c8V+cBwB1pmYE61JFNeluCT8ZeKa+Bspcq5TpjBUgZXa pSRCczfO+xxDISzp6Ubkju+7BTxHlLu3OB9PUVwkuPSsiZlOsJ5y9Yk8EN2F8Xbe87Ff R5cCFtSa0iBAOeK8qngcuLrzfKai9WsECzf2YwAhzyEeCXsv+8fkHM71rkuaurqyo/m7 Tq2PydXRFVC1i0kA+gYz8fziiF7He4Hb/a7y3vkCYNloUgWxyqO8pnSDir8Bwl+Tq7Ro MjwA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id w11-v6si842147eda.3.2018.10.18.03.29.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 03:29:49 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id w9IATmZw008830 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 12:29:48 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w9IATmFu003917; Thu, 18 Oct 2018 12:29:48 +0200 Subject: Re: [PATCH] image: include image name in the kernel/initrd image copies To: chombourger@gmail.com, isar-users References: <1539853468-156-1-git-send-email-Cedric_Hombourger@mentor.com> <578d4e7b-292e-3795-08d7-041c9abe80ee@siemens.com> From: Jan Kiszka Message-ID: <695f9e56-13af-9a25-df97-4f1b8a11a364@siemens.com> Date: Thu, 18 Oct 2018 12:29:47 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 8IhDUDmBVD82 On 18.10.18 11:46, chombourger@gmail.com wrote: > > Hi Jan, > > See below > > On Thursday, October 18, 2018 at 11:27:10 AM UTC+2, Jan Kiszka wrote: > > On 18.10.18 11:04, Cedric Hombourger wrote: > > The kernel and initrd images are really image-specific (especially the later > > with the initrd being created/updated as packages get installed into the > root > > file-system). Make sure we retain a per-image copy of these images in the > > I don't buy this argument yet: Which additional parameters besides the and the > MACHINE make kernel different? > > > 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. > > 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) 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. > > If there is any, can't we associate that > variation more directly with the image then? It's surely not the image > recipe name. > > > Would you have a suggestion (based on the extra info I provided above)? > > A possibly cleaner solution would be to NOT copy these files > into DEPLOY_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 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. 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. Furthermore, we likely need to update things like do_copy_boot_files[stamp-extra-info], do_populate_sdk[stamp-extra-info] to follow those patterns as well. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux