public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Dong, Eric" <eric.dong@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"brian.johnson@hpe.com" <brian.johnson@hpe.com>,
	"Bi, Dandan" <dandan.bi@intel.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: "Ni, Ray" <ray.ni@intel.com>,
	"Wang, Jian J" <jian.j.wang@intel.com>,
	"Wu, Hao A" <hao.a.wu@intel.com>,
	"Tan, Ming" <ming.tan@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules
Date: Sat, 20 Jun 2020 04:30:56 +0000	[thread overview]
Message-ID: <DM6PR11MB327404B914E96EAA4292540CFE990@DM6PR11MB3274.namprd11.prod.outlook.com> (raw)
In-Reply-To: <c0f84ff3-4a57-1444-6e7d-efa42f4c9d6a@hpe.com>

[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Brian J. Johnson
Sent: Saturday, June 20, 2020 1:29 AM
To: devel@edk2.groups.io; Bi, Dandan <dandan.bi@intel.com>; rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Tan, Ming <ming.tan@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

On 6/18/20 2:01 AM, Dandan Bi wrote:
Hi All,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2816

We plan to separate two kinds of NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn't impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it's also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
  <LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
    ...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf  {
  <LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
    ...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
  <LibraryClasses>
    NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
    ...
}


Thanks,
Dandan



Dandan,

We'll have a lot of layers of indirection....  The ReportStatusCodeRouter modules will call one or more StatusCodeHandlerModules, and the standard StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries.

How about adding StatusCodeHandlerLib support directly to the ReportStatusCodeRouter modules?  Then platforms could omit the StatusCodeHandler modules if they're only using the open-source code.  That sounds like less overhead since fewer modules would be needed



Hi Brain,

You are right. Current design truly has a lot of layers. The ReportStatusCodeRouter module provides the register logic and maintain the registered status code handlers. Now the platform may have more than one of drivers used to register the status code handler.  This RFC used to resolve the platform has more than one status code handler drivers' issue. We expect the platform only need one wrapper driver in MdeModulePkg to let the status code handler library to register its handler on it.

Thanks,

Eric



Thanks,
--

Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

hpe.com<3D%22hpe.com%22>


[-- Attachment #2: Type: text/html, Size: 11670 bytes --]

      parent reply	other threads:[~2020-06-20  4:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18  7:01 [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules Dandan Bi
2020-06-19 12:48 ` Laszlo Ersek
2020-06-22  4:57   ` Dandan Bi
2020-06-22 15:02     ` Laszlo Ersek
2020-06-19 17:29 ` Brian J. Johnson
2020-06-19 18:03   ` Andrew Fish
2020-06-22  7:27     ` Dandan Bi
2020-06-24 20:24       ` Brian J. Johnson
2020-06-25 15:41         ` Dong, Eric
2020-06-25 22:26           ` Brian J. Johnson
2020-06-20  4:30   ` Dong, Eric [this message]

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=DM6PR11MB327404B914E96EAA4292540CFE990@DM6PR11MB3274.namprd11.prod.outlook.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