From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by mx.groups.io with SMTP id smtpd.web12.417.1583862898303418937 for ; Tue, 10 Mar 2020 10:54:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=qkQLMdq2; spf=pass (domain: linaro.org, ip: 209.85.128.66, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f66.google.com with SMTP id f7so2401551wml.4 for ; Tue, 10 Mar 2020 10:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zjID9yTqMt5Dkl60wYCHsD+AoRVlzkL5cqIyBaA51uU=; b=qkQLMdq2rXy1Zz18phMBdzuehL7wJkYvqVG97Wo/BbhLjrBHwPCq6S/7TL7vg1srJu jDojvnYOZ6jd+ssQhXcUbsa7US4agDVStJ2IvCvRjuJZ3RhKw6Q/qfvtidtuA0UZqaLT UVUm3ZrWeNvAJfsCzrx1gnaBdVR7SLE15jfcQSzn+diCajp7hyOhMN6zwuh+RUy4Fre9 2cdcgnR5XcAalpZ4Qi4r7wZsoyQJd12cK40vkcao0O7gAapljaudxMNGpcpnHS7yZnA3 l4EOzCLWtAzwGQcd/dCZphOWY2j27+tsEwrIpwIDiv3Ni7OHcCAp4vLHihX5HJit/yfp uSzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zjID9yTqMt5Dkl60wYCHsD+AoRVlzkL5cqIyBaA51uU=; b=sDowhINBtFhEuanlqg0ov9dX28bmLtxjD8WxGLKsuM3ZR4aPBEd4UPLbYf2SsnAQaz HEQ4LXFWQCfYWOMIM7A5ePwv+CnCAURr9rDR5XAXyVuw4YFrpxIH6w8Qzv1g4GlEIysS J+HLD5HWQ4igFAj6xRD+iEZ8DDpnhPnw5kkYxUiMGs7xK6JByiLTdkIdIKNK5FenCJ5/ q+JT6I+7cjbynSppAvsn/JGCWWa6zE835fk9VGQNleR1hFO3lhmcLxdUwIoE509aw6qC /1yt/4v54Z5j1vEIIpLIWBNns65njazlKst/ZrZEDibe/QKd2+A36q1b0rhSyvkr412M rwNA== X-Gm-Message-State: ANhLgQ0HlKboBfK62tpSR/0LO12atlGeFaUYjDVwE4LlPRHyTR1RYYCS f/0WSM5PMi1sV1L7ZQPYOGQQ48w5GERh2gs4i2OSiXDdEOiDAw== X-Google-Smtp-Source: ADFU+vs1g0lDRi+jats11gsEtFIGujvcS/ZflHQsgy/ID8U4RUMSNSfjql/E8GFQlxaDezzPM9kCvcQo5411Yxb82og= X-Received: by 2002:a1c:4483:: with SMTP id r125mr3160769wma.62.1583862896390; Tue, 10 Mar 2020 10:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:ed51:0:0:0:0:0 with HTTP; Tue, 10 Mar 2020 10:54:55 -0700 (PDT) In-Reply-To: <21546.1583861100642932695@groups.io> References: <6ef172e5-4999-f1bc-0d08-43685b03f5ce@redhat.com> <21546.1583861100642932695@groups.io> From: "Ard Biesheuvel" Date: Tue, 10 Mar 2020 13:54:55 -0400 Message-ID: Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: devel@edk2.groups.io, sean.brogan@microsoft.com Cc: Laszlo Ersek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For me, the issue is more fundamental than what Laszlo describes. The platforms that target qemu, which is available to anyone, can run on any host, and can boot various OSes beyond Linux (including windows), which is their primary target. It even supports virtualization, which is highly significant on arm, given the tricky cache maintenance and things like aligned access and dc zva instructions, which qemu does not catch in emulation mode. This means we can reasonably require any contributor not to regress on those platforms, given how they have full access to it, and this is actually where i would like us to take the next step when it comes to ci automation, i.e., automatically flag PRs that break the boot on a selected set of qemu based configs. Putting those platforms in a separate repository complicates this to the extent where it is no longer feasible to reason about the core repository being in a working or broken state, given how intrusive changes usually require changes on the platform description side as well, and I don=E2=80=99t see the validation tools handling two repositor= ies in parallel. Beyond this, i have no fundamental objections to moving things out of the core, and i=E2=80=99d remove more cruft from ArmPlatformPkg or Embedde= dPkg if i could (including, e.g., the PrePi SEC code that should have never existed) On 10/03/2020, Sean via Groups.Io = wrote: > I don't see the difference besides the mechanics of the operation (which= you > have described clearly).=C2=A0 To guarantee a repo or repos is "git-bise= ctable" > you need to build and test every commit on your platform.=C2=A0 For exam= ple in > the recent ArmMmuLib patchset, you were able to build every commit in th= e > patch to identify which one caused the break.=C2=A0 There isn't an enfor= ced > process in place to ensure that happens within Edk2.=C2=A0 Thankfully th= e review > process and the developers knowledge allowed the commits to be made in s= uch > a way that this was possible.=C2=A0 That doesn't have to change when you= move to > a submodule.=C2=A0 Also you could put automation in place to enforce and= /or test > for this scenario.=C2=A0 You can put automation in place to "integrate" = into your > super project at every commit if you really wanted to and had the resour= ces > to run tests on every one of those commits.=C2=A0 Is this type of CI don= e today > for OVMF? > > Again this is what nearly all platforms have to do today and we have a l= ot > of experience with bisecting within the submodule to find the error.=C2= =A0 The > longer you wait between integrations the more costly the bisect is if yo= u > have to do it, but this is a choice of the super project owner / platfor= m > owner.=C2=A0 Today I assume you make those choices too, they just happen= to be > within the same repo.=C2=A0 I also assume that if you found the MmuLib b= ug in a > few days you probably wouldn't bisect all the changes but you would revi= ew > the history to intelligently guess at the most likely candidates and bis= ect > within those commits. > > In the end I just don't see the big difference to the platform (OVMF in = this > case) but I do see the reduced size/noise/content helping all platforms. > Success still relies on good development practices, regular builds, and > testing. > > Thanks > Sean > >=20 > >