From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 358091A1E0B for ; Tue, 2 Aug 2016 01:29:05 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87C35C049E18; Tue, 2 Aug 2016 08:29:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-83.phx2.redhat.com [10.3.116.83]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u728T3sC023122; Tue, 2 Aug 2016 04:29:03 -0400 To: Cinnamon Shia , edk2-devel@ml01.01.org References: <20160801070856.3008-1-cinnamon.shia@hpe.com> <810d8084-8758-1eca-0550-19ef8e707f91@redhat.com> Cc: jordan.l.justen@intel.com, liming.gao@intel.com From: Laszlo Ersek Message-ID: <99d9ec37-31ff-a92e-bd59-e5f3b7fa3616@redhat.com> Date: Tue, 2 Aug 2016 10:29:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <810d8084-8758-1eca-0550-19ef8e707f91@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 02 Aug 2016 08:29:04 +0000 (UTC) Subject: Re: [PATCH] OvmfPkg: use StatusCode Router and Handler from MdeModulePkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 08:29:05 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/02/16 03:13, Laszlo Ersek wrote: > (1) So, here's what I would like to see in the commit message: > > ---------- > > In the Platform Init v1.4a spec, > - Volume 1 "4.7 Status Code Service" defines the > EFI_PEI_REPORT_STATUS_CODE.ReportStatusCode() service, sorry, the above is a typo, I meant EFI_PEI_SERVICES.ReportStatusCode(). > - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the > EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), > - Volume 2 "14.2 Status Code Runtime Protocol" defines the > EFI_STATUS_CODE_PROTOCOL. > > These allow PEIMs and DXE (and later) modules to report status codes. > > Currently OvmfPkg uses modules from under > "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above > abstractions (PPI and PROTOCOL) directly, and write the status codes, as > they are reported, to the serial port or to a memory buffer. This is > called "handling" the status codes. > > In the Platform Init v1.4a spec, > - Volume 3 "7.2.2 Report Status Code Handler PPI" defines > EFI_PEI_RSC_HANDLER_PPI, > - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines > EFI_RSC_HANDLER_PROTOCOL. > > These allow PEIMs and runtime DXE drivers to register several callbacks > for status code handling. The woring here would also be better if we said "These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling". In other words, "several" should refer to the drivers, not the callbacks. > > MdeModulePkg offers a PEIM under > "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that procudes both > EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE > driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" > that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. > > MdeModulePkg also offers status code handler modules under > MdeModulePkg/Universal/StatusCodeHandler/ that depend on > EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. > > The StatusCodeHandler modules register themselves with > ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / > EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code > through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches > phase-matching ReportStatusCodeRouter module first, which in turn passes "it reaches [the] phase-matching" -- the definite article missing. Sorry about these typos, it was very late last night when I wrote the email. Thanks! Laszlo > the status code to the pre-registered, phase-matching StatusCodeHandler > module. > > The status code handling in the StatusCodeHandler modules is identical > to the one currently provided by the IntelFrameworkModulePkg modules. > Replace the IntelFareworkModulePkg modules with the MdeModulePkg ones, > so we can decrease our dependency on IntelFareworkModulePkg. > > ----------