From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6739560601010307072 X-Received: by 2002:a2e:6a13:: with SMTP id f19mr12742731ljc.17.1569857980443; Mon, 30 Sep 2019 08:39:40 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:8803:: with SMTP id x3ls1564150ljh.10.gmail; Mon, 30 Sep 2019 08:39:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqw6yaEaX0CByFGHQbdI3TIDxwR9q1LX3T5kMuVEVDuHo7VFG2dP89uu3TgFKrZwce52Y8x2 X-Received: by 2002:a2e:9b5a:: with SMTP id o26mr12659644ljj.158.1569857979863; Mon, 30 Sep 2019 08:39:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569857979; cv=none; d=google.com; s=arc-20160816; b=lGLr0ZI8if8//1kPpRHjJonfkmgBCHhH6jeqaF8aDQkBEHmOFmkfcA5WoWO7+u2Jr3 gh77zpnkiZj7zcNA+zRD86r5/LWCSTlJQm+jDy2wY9VmYQEBrDKxonUWeX08BrAw+pWo DGHrte7+/o4bLCYlUdYqMrYYjcuQya9+FZ1kpX01fK8dSoHKjlHoXyPd86UHatw6CjSA L9WQI0dPr5NXyXqXXBKXrFvzR/zzIcaHKcciikdjtduIem7lN9L4GWgZbgXSHxlAWgrQ vLtXEkEGtS4FTn3X5fozTFZaNI/aUaJwrIpoixWTBW6v9Een9LNRLOeO6CLF/kQer29b bVQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=Yrs+8mp9kVHdm0toIJ05yNSLYpo73/qhhQBWDH1XQzs=; b=oKSyu1cHzw5lnzg98PZKXfV9vhzVjyYsVeJX8H030Xj613ubGeFfHpjh3YSrTHUyp9 9gbPSh7lI2eUpTDblwziO7k9lwmoZDWXQunlNqwvVGZyEY7i3xRq5SzcCBpAxoin2Ees HQpLXviYkVhuE6JqCbsL5RJG6YJ92hGqvLbHSFfcthKl++gj+GBQTjf9JtOextL4wxMg eVJw+Jy5EgCN34kzp67Lpo7gK/kuXraSckqwmUzi3IbBS2xo36wr83d/YhskAJnM0wam 44nYhe/hTX2L+0vrhRy+vUz301SEfayMR2igMAqWBd5lmBilCdLFrrmBJ6ZrX8ud2Cxc hTUA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id q25si598689ljg.5.2019.09.30.08.39.39 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Sep 2019 08:39:39 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x8UFdbuD007047 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Sep 2019 17:39:38 +0200 Date: Mon, 30 Sep 2019 17:39:37 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH v6 12/27] Detect false sharing of recipes Message-ID: <20190930153937.n4rvim46yz7k2vc4@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <5a2e329b881ec0b392d0f1abd116f1deeee0f66f.1569176231.git.jan.kiszka@siemens.com> <20190929145700.ads3zbq7hz77olcw@yssyq.m.ilbers.de> <248aa6db-6327-9604-40b6-e7135a5f9961@siemens.com> <20190930095610.shyewhozb46dautr@yssyq.m.ilbers.de> <20190930145326.prsfzcxogzebwbll@yssyq.m.ilbers.de> <5cb07f77-c81f-53ee-7b4c-183e5609ae4c@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5cb07f77-c81f-53ee-7b4c-183e5609ae4c@siemens.com> User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: 32FSekM96nd4 On Mon, Sep 30, 2019 at 05:26:07PM +0200, Jan Kiszka wrote: > > Ok, thanks for the explanation. You unshared the host rootfses for Debian armhf > > and Raspbian armhf. After that, the locks in isar_bootstrap() and > > do_apt_config_prepare() are indeed not necessary. > > > > Actually, sharing both was an intended optimization because the resulting host > > rootfses are identical. However, the implementation drops one via locking and > > not via bitbake pipeline, and isn't executed on config change. Not sure how > > difficult it would be to do that right. I can merge #9 and #10 for now. > > As the commit log stated, this assumption ("are identical") was wrong in the > first place. To make it clear, that was just an explanation why it had been done, I didn't intend to challenge your motivation. With stock Isar and your both series applied, a quick cd tmp/deploy/bootstrap; sudo diff -Nrq debian-stretch-host_debian-stretch-armhf debian-stretch-host_raspbian-stretch-armhf results in: diff: debian-stretch-host_debian-stretch-armhf/lib64/ld-linux-x86-64.so.2: No such file or directory diff: debian-stretch-host_raspbian-stretch-armhf/lib64/ld-linux-x86-64.so.2: No such file or directory Files debian-stretch-host_debian-stretch-armhf/var/cache/apt/pkgcache.bin and debian-stretch-host_raspbian-stretch-armhf/var/cache/apt/pkgcache.bin differ Files debian-stretch-host_debian-stretch-armhf/var/cache/apt/srcpkgcache.bin and debian-stretch-host_raspbian-stretch-armhf/var/cache/apt/srcpkgcache.bin differ Files debian-stretch-host_debian-stretch-armhf/var/cache/ldconfig/aux-cache and debian-stretch-host_raspbian-stretch-armhf/var/cache/ldconfig/aux-cache differ Files debian-stretch-host_debian-stretch-armhf/var/log/alternatives.log and debian-stretch-host_raspbian-stretch-armhf/var/log/alternatives.log differ Files debian-stretch-host_debian-stretch-armhf/var/log/apt/history.log and debian-stretch-host_raspbian-stretch-armhf/var/log/apt/history.log differ Files debian-stretch-host_debian-stretch-armhf/var/log/apt/term.log and debian-stretch-host_raspbian-stretch-armhf/var/log/apt/term.log differ Files debian-stretch-host_debian-stretch-armhf/var/log/bootstrap.log and debian-stretch-host_raspbian-stretch-armhf/var/log/bootstrap.log differ Files debian-stretch-host_debian-stretch-armhf/var/log/dpkg.log and debian-stretch-host_raspbian-stretch-armhf/var/log/dpkg.log differ I.e., no differences. For my understanding, do you have host bootstrap differences downstream? What are they? Maybe we could add a test case for that. With kind regards, Baurzhan.