From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6691606441411739648 X-Received: by 2002:a1c:80d7:: with SMTP id b206mr2402025wmd.48.1558425977055; Tue, 21 May 2019 01:06:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:8184:: with SMTP id 4ls4763762wra.5.gmail; Tue, 21 May 2019 01:06:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqzPvROShmszrt5i+XzOWjsGr8c078NcO95d1lq/lW88yBE6nQkVIf2jRV+kXSZCNqhciEyc X-Received: by 2002:adf:cc8b:: with SMTP id p11mr33685900wrj.13.1558425976666; Tue, 21 May 2019 01:06:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558425976; cv=none; d=google.com; s=arc-20160816; b=qKWwqSKd6MaKju0jBWIXvm8JWrVX+BxcUt2VEKicYosOb0Z4Js5PDdTb+1eDKgp98s QlZBkmb737x9L8HH9y8u8DiwuNXWCfo5Vm1u73wjooFqtLlNM59adjjPiJw2AGkty3+6 0aScBRIPgUalcUYq1OMve32wWKKZKoyB00I2IrfoxinznkGaqvbQ/L23Yf/oy8iKSPVl 1P5lET/MEjfLUZDOzSMdQIVTwnDDNqqVTg9g6+1rfTAdOVgcLqbpo+zkcc/2pIwTA2J/ JXuennKeqGGj8PxUM5awMMOHCkGmcLJPC7coGu3MIZl8feMqu9kuOVMz9rMoufKs/IRf bSIA== 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=zyDqkw0vaqNBCFYPt9HLJlafKWSbmMsviAxcNfS5upk=; b=rZ8KJ5IjPtw0H9J/vLjJjhoilWTCFqdkIMJ9GVwe5sPwWS4zM7/0pfE8c0c0jW4PZM y0ypMcSJJvlotfsd12VGusdiYGjvNpurOTqX6rsLwozPZ3yyDmCeLYqQyyYp/vOdtp2i tmxlLZc7KYf8HH8J4B4gwNTN+RSwtRDlf89N4UeEWscXZYcVoCMTgJqUc3FWxIjw1tid 7d5mHcuufiTc4uslp2n7uX9fKVbA8XMqcdYr7yISzjvMt+RlXedBU5zkBNqT4GynIRrT oksBy9kpCU1KykPSOCEQL1QlFLv0jV9FCsnPYs3k0m8Y2e7b0odHrJVzHIVb4MpZU+Uc iEiQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id h189si44881wmh.2.2019.05.21.01.06.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 May 2019 01:06:16 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@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 claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=claudius.heine.ext@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 david.siemens.de (8.15.2/8.15.2) with ESMTPS id x4L86GY5010740 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 21 May 2019 10:06:16 +0200 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x4L86Gix007726 for ; Tue, 21 May 2019 10:06:16 +0200 Subject: Re: [PATCH 2/2] Revert "meta/classes/image: Call transform_template after rootfs_install" To: isar-users@googlegroups.com References: <20190516125030.13190-1-claudius.heine.ext@siemens.com> <20190516125030.13190-3-claudius.heine.ext@siemens.com> <7de18f5d-e5ca-49ba-2497-ab70a0508c66@ilbers.de> <729803d9-2ce2-4de4-c121-a7d1d90842a7@siemens.com> <20190520194710.GI21981@yssyq.m.ilbers.de> From: Claudius Heine Message-ID: Date: Tue, 21 May 2019 10:06:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190520194710.GI21981@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: Duf6xe3iW7b2 Hi Baurzhan, On 20/05/2019 21.47, Baurzhan Ismagulov wrote: > On Mon, May 20, 2019 at 09:19:41AM +0200, Claudius Heine wrote: >> Because this change just painted over the underlying issue with the >> non-deterministic and volatile value of the KERNEL_IMAGE and INITRD_IMAGE >> variables. So I would not consider that a permanent fix but a quick >> band-aid. > > The function returns different values depending on whether the respective task > has finished. So, the implicit precondition is that the caller must depend on > the kernel deployment task. Given the precondition, the behavior is > deterministic and there could be other ways to fix them without sacrificing > user experience. ? I don't understand you here. From my perspective is this patchset now merged and the issue is fixed without sacrificing user experience. Or do you have any issue with how it was fixed? If so, then a patch review would be nice. > > For my understanding, what was your user-level use case when you experienced > the get_image_name() issue? As I already described previously, there is only a very specific time frame in the image build process where `get_image_name` is allowed to be called and that is after the kernel package is installed and before the kernel is removed from `/boot` in a possible post-install cleanup step. After this patchset `get_image_name` is only called in one task (`do_copy_boot_files`), so it can be safely removed and integrated there to avoid any misuse of that function. I also think that is is much easier to implement there and thus removes complexity and improves code readability. > To be clear, Maxim's patch only addresses CI and not this issue. I know, and that was exactly what I commented on the patch. What the revert in Maxims patch set did was a zero sum improvement: one issue fixed and another caused. I would have rather seen either to fix the issue (for instance the way I described in the review of Maxims patch set and this patch set does) or to disable the test in the CI until the issue is fixed correctly. That way either the issue in the code or that CI is 'red' would have been fixed and that would have been both a positive change instead no change. A "revert" for me means that a patch does not do what it was meant to do or is useless. If it was found that a merged patch accidentally caused a regression, then instead of reverting that commit and knowingly causing further regressions, the regression of that patch should be fixed directly. From that conviction, Maxims revert patch just seems petty to me. regards, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de