public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: devel@edk2.groups.io, daniel.schaefer@hpe.com,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Chang, Abner (HPS SW/FW Technologist)" <abner.chang@hpe.com>,
	Atish Patra <atishp@atishpatra.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Atish Patra <atish.patra@wdc.com>,
	Alexander Graf <agraf@csgraf.de>, Anup Patel <anup.patel@wdc.com>,
	"leif@nuviainc.com" <leif@nuviainc.com>,
	jordan.l.justen@intel.com
Subject: Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from?
Date: Thu, 7 May 2020 15:24:17 +0200	[thread overview]
Message-ID: <3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com> (raw)
In-Reply-To: <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com>

On 5/7/20 3:18 PM, Daniel Schaefer via groups.io wrote:
> Hi Ard and others,
> 
> TLDR; We have APRIORI definitions from other places in EDK2 but there's 
> no explanation as to why they are there.
> 
> I'm taking this to the EDK2 list, since it doesn't concern U-Boot.
> I kept some other people related to UEFI, maybe you're interested ;)
> 
> On 2/25/20 10:07 AM, Ard Biesheuvel wrote:
>  > What I did notice is the use of APRIORI PEI and APRIORI DXE sections
>  > in your platform descriptions. I recommend you try to avoid that, as
>  > it is a maintenance burden going forward: instead, please use dummy
>  > protocols and NULL library class resolutions if you need to make
>  > generic components depend on platform specific protocols. Also, please
>  > document this - the APRIORI section does not explain *why* you have to
>  > circumvent the ordinary dependency tree based module dispatch.
> 
> I'm taking a look at this right now.
> You're absolutely right - we should reduce or document APRIORIs.
> 
> However, Abner told me that he had only copied most of the FDF from other
> places in EDK2.This is what we currently have:
> 
> APRIORI PEI {
>    INF 
> MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf 
> 
>    INF 
> MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
>    INF  MdeModulePkg/Universal/PCD/Pei/Pcd.inf
> }
> APRIORI DXE {
>    INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>    INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>    INF 
> Platform/SiFive/U5SeriesPkg/Universal/Dxe/RamFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
> 
> }
> 
> I can remove all of APRIORI PEI and it boots properly. Of the DXEs I can 
> only
> remove FvbServicesRuntimeDxe, otherwise some DXEs are dispatched in the 
> wrong
> order and boot fails.

This means some modules have an undeclared dependency on one of the 
remaining modules. Can you elaborate on how the boot fails in this case?


  reply	other threads:[~2020-05-07 13:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200224221949.28826-1-atish.patra@wdc.com>
     [not found] ` <dcab6806-fa1c-8c7e-b0dc-2d96c017872d@gmx.de>
     [not found]   ` <CAKv+Gu_-1BrjiKKw6qa9a6vjXHrf=iYa1oaKCRr5HZf0HM+mZA@mail.gmail.com>
     [not found]     ` <CAOnJCULfew0aZ3FiDQAZZTPjzE5bvdN5of5AP_r6_1W+CQDh=A@mail.gmail.com>
     [not found]       ` <TU4PR8401MB0429018FEDB13B1057A452E4FFED0@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>
     [not found]         ` <CAKv+Gu9vSVMg3L++7xM2LYV7XPoMtY-E1HXZa290srk0CfBqig@mail.gmail.com>
     [not found]           ` <TU4PR8401MB04290CF16E0037DD90FDAE15FFED0@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>
     [not found]             ` <CAKv+Gu9kuiOag+BV5--QbhkEFCD8q8FJFzQ=uYV=oEMfrAo0Zg@mail.gmail.com>
2020-05-07 13:18               ` APRIORI in RISC-V or Where did OVMF APRIORIs come from? Daniel Schaefer
2020-05-07 13:24                 ` Ard Biesheuvel [this message]
2020-05-07 13:43                   ` [edk2-devel] " Daniel Schaefer
2020-05-07 13:53                     ` Ard Biesheuvel
2020-05-07 16:42                       ` Andrew Fish
2020-05-07 16:45                         ` [EXTERNAL] " Bret Barkelew
2020-05-07 16:54                           ` [EXTERNAL] " Andrew Fish
2020-05-07 17:00                             ` Michael D Kinney
2020-05-08 11:05                           ` [EXTERNAL] " Laszlo Ersek
2020-05-08  9:48                       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox