From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web10.1716.1583831162520424647 for ; Tue, 10 Mar 2020 02:06:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hbyLwjyN; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583831161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ik26uX4pbSU1HHLZfV1h/I+OPJCbSyJu67f12jY9dWk=; b=hbyLwjyNsVxOO0nj4XtgiGxrtyESZxFj5uSYBKmvb90+akxhIXNcOVADMkB09BVBjE93fo XA/6vmB3Vh/xc4rqwjdjPLXREemRUTKBcEyfLezX+d5nYQZuqrG6FlMam6+8I3mfrvzQ9z wJ5NSiL5T3nVgMZgD+kpm5e2P+IfVK8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-444-Xu-IzLChPq-tcq7Bsjo0SQ-1; Tue, 10 Mar 2020 05:05:57 -0400 X-MC-Unique: Xu-IzLChPq-tcq7Bsjo0SQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DBC76477; Tue, 10 Mar 2020 09:05:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-246.ams2.redhat.com [10.36.116.246]) by smtp.corp.redhat.com (Postfix) with ESMTP id 04BD61000325; Tue, 10 Mar 2020 09:05:55 +0000 (UTC) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: Sean , devel@edk2.groups.io References: <620e6fb0-45ab-c8ed-8881-a907dc4cc030@redhat.com> <1758.1583805050303399990@groups.io> From: "Laszlo Ersek" Cc: Ard Biesheuvel Message-ID: <6ef172e5-4999-f1bc-0d08-43685b03f5ce@redhat.com> Date: Tue, 10 Mar 2020 10:05:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1758.1583805050303399990@groups.io> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/10/20 02:50, sean.brogan via [] wrote: > [...] There are numerous ways to keep multiple repos in sync that > allow a user to root cause regressions. Using submodules is one way > to easily track the version of edk2 that was/is used in the platform > repo and when issues are identified the commit history can be > bisected to find the problem. [...] I disagree. Running git-bisect on a commit range in the superproject will identify the submodule update commit as the one introducing the regression, yes. But I don't see a way forward from that point onward. The goal of git-bisect is to identify (pinpoint) the smallest atomic change that's related to a regression. A submodule update is the polar opposite of an atomic change. Delving into the submodule itself, for a git-bisect -- i.e., bisecting the submodule between the boundaries set by the superproject's submodule update commit -- is not something that can be relied upon. Namely, a core trait of git-bisect is that it tests states of the whole project that have *existed* at some point. But a combination of: - the superproject checked out at any particular point in its own history, - and the submodule checked out strictly *between* two such adjacent commits that have ever been actively consumed by the superproject, is not a state like that. Such states may not even build. They may never have been tested, put through CI, and so whether they work or not is inconsequential -- they should not be *expected* to work. Such states don't qualify as "checkpoints". That's because a submodule is unaware of all the superprojects that consume it. Whereas, in a shared git history, every single commit counts as a checkpoint -- a combined state that has existed at some point. You can solve this problem (in the separate repository model) only if you build and test every known platform (= every known superproject) against every single patch (not series!) that is proposed for the core (= the submodule). Importantly, it's not enough to build and test the superprojects at the ends of the submodule (= core) patch sets, because that still leaves the checkpoints two far apart. The full platform testing (for all platforms) would have to be done at every stage of the submodule (= core) patch series. Turning a codebase (such as core edk2) into a submodule for a superproject (such as OVMF) is equivalent to saying, "we trust the submodule that, at distinguished checkouts, it holds up all its contracts". That's exactly what I don't trust the core of edk2 to do, and those contract violations are exactly what git-bisect is designed to root out. The edk2 bisection that I've performed most recently was less than nine hours ago. It identified a regression in a core (non-platform) change, namely "ArmPkg/Library/ArmMmuLib": https://edk2.groups.io/g/devel/message/55701 It was doable because git-bisect was aware of six patches that had been applied in a row on ArmMmuLib against a single ArmVirtQemu platform state. I may not be knowledgeable enough about git-bisect, of course; I've asked my teammates internally if they have positive experience and/or recommendations with git-bisect across submodules. Thanks Laszlo