From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mx.groups.io with SMTP id smtpd.web10.5492.1592627459782979224 for ; Fri, 19 Jun 2020 21:31:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=HuXEh2tF; spf=pass (domain: intel.com, ip: 192.55.52.151, mailfrom: eric.dong@intel.com) IronPort-SDR: HWTsZB54TdMAYyHBrW2ewjRQ4BxHWGtHusErCGDDzPjmDng3fIS005Hrb0xrSAMNEmoW4SCE5g AkNsnCmviNTw== X-IronPort-AV: E=McAfee;i="6000,8403,9657"; a="123465278" X-IronPort-AV: E=Sophos;i="5.75,257,1589266800"; d="scan'208,217";a="123465278" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2020 21:30:59 -0700 IronPort-SDR: 1VODE8lRWC0uO2YraS407r+sYLtwINmwYm3FJ3XC5v7eKUjCn7Ac9h2XcKEBqz5oMBuYVgckSc 0foy/kszB/tg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,257,1589266800"; d="scan'208,217";a="274487423" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga003.jf.intel.com with ESMTP; 19 Jun 2020 21:30:59 -0700 Received: from orsmsx124.amr.corp.intel.com (10.22.240.120) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 19 Jun 2020 21:30:58 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX124.amr.corp.intel.com (10.22.240.120) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 19 Jun 2020 21:30:58 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.41) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 19 Jun 2020 21:30:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TLXsTFo4k0xAVnUzpm50jrACk/PKpBulruUsgwvwDqRRHrKYDSNnYOoFDWJ/dQiMFCdQMKfLcpDMkkoerIipuyaCG4xmVshAPet2m60pAgRxhS542UA92K3OhYcvz7yHyLdr7xNIhtFdShZdZ1dQYsGVyqxIPm7AeBxk2dr9a/i6kjnssqRMfoQVLKIzGg7ZnxIfMV2ttGDQfH1LEtXjPQL5AWJXVPlBV0Buqwi/zAcXUI+4EshDNDRs4DhZqP4FfG56FGTigBhoNal2dLKWZnwEVRLF8jv7zjN1fFgGlayzEhnp96lMUi21Z5A6ARUFSdoULcR3oGO7g2bXNcDFPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K8X5N4CMbs3kewQjLl8/HCfhs+0ZRSchYot/ieZmipg=; b=a30YZEalHi0q9bP44zLjqrqHKRAwaaaydFVadyZNY9jE2cfjJRNPGsVesSRPmwv8GWpD0SvXaHYWpcjHwZfF6huz8Ypeik+WEKBjAgnkMFveBaUPOAjk2bZvjJEzDGn3J1zZgNyLzWRTh0fRX1ZaPPVaUPTxVeKlheRo9n8WPQg3yRkFjqlCkgIvM7BTx+0Bq7cWfY+p+NYEWeo6CufqY87R2WepFjnEfO4Ql0S21P10g4MD1G7YhfftxUP4qUPjLseNJljE5MVMQ7vjiFG8OcjWVOG+pAKqpNmLc3EZ8IrGuJpl2SgExtio5q2+ni2TCRkK4A2BIepp5VdFgxWvKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K8X5N4CMbs3kewQjLl8/HCfhs+0ZRSchYot/ieZmipg=; b=HuXEh2tFUn9MvMBjYujC/WsnuFxWsTqkzRmdwOjqtoW942P1qUMo8bE0UmChqjGGCtl79A5Fz0DJ655cQ/jASXchmQedI1Y+yWDruYfccwh7UGFRomF13lbNHsoCoEseuXn5pE1EeokGSU1MEEiGiyLaGy1TwGdX7lIna7JM9qE= Received: from DM6PR11MB3274.namprd11.prod.outlook.com (2603:10b6:5:b::26) by DM6PR11MB4609.namprd11.prod.outlook.com (2603:10b6:5:28f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Sat, 20 Jun 2020 04:30:56 +0000 Received: from DM6PR11MB3274.namprd11.prod.outlook.com ([fe80::cc01:6f05:1402:e7d7]) by DM6PR11MB3274.namprd11.prod.outlook.com ([fe80::cc01:6f05:1402:e7d7%6]) with mapi id 15.20.3109.021; Sat, 20 Jun 2020 04:30:56 +0000 From: "Dong, Eric" To: "devel@edk2.groups.io" , "brian.johnson@hpe.com" , "Bi, Dandan" , "rfc@edk2.groups.io" CC: "Ni, Ray" , "Wang, Jian J" , "Wu, Hao A" , "Tan, Ming" Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules Thread-Topic: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules Thread-Index: AQHWRl86QTH482Qo80+pLWl1cX2p36jg42oQ Date: Sat, 20 Jun 2020 04:30:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.102.204.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d4c52ea2-cdb5-4398-d880-08d814d2b992 x-ms-traffictypediagnostic: DM6PR11MB4609: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0440AC9990 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2iCaVsy42LS7KmbpoJwkFULfqTii3lrskDJxStFWX9CQhyN8pVfP4NNJwx/Vc/pD2PYlkTgzXCRC1qvCK0PXkCPg5toI7M5inlUP3fqGMaXEvFZehSbauabaiUUZhTOa3KPLz6c/a5xcDTboQuoFGuKVgjDFEF3G+QGYcGLKTzGylyVTl6eGgT3IPXOxJidyeYziMepmtwjDbL4XvRKyDZWYOdEPiYk+8YDuE1ThjTCP4G0xiA+iQGji24BW4nM1fq80fH6hQ76l0AaHDzYjhrrZnM0ZTUiH3HwD7TRJ0+2MQVjxEUGEJX26/9ecA2edv8H3Pj2KPbcLHDn5T6X6L3/sqi2FVsFwK0Dic0RG4lRHof8yjZC14HISH78toHv/vY+BiCh/C2uMNMcxXe3P8g== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR11MB3274.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(71200400001)(8936002)(5660300002)(4326008)(107886003)(52536014)(9686003)(55016002)(83380400001)(66446008)(66556008)(86362001)(66946007)(33656002)(64756008)(66476007)(478600001)(76116006)(186003)(2906002)(53546011)(6506007)(7696005)(8676002)(76236003)(54906003)(166002)(316002)(966005)(110136005)(26005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: IggXYYPXQbW8qtYYJdt4ynFAjd/xOoIYhWL9Z5EquD4mnjtq6K4FcEsW1ee+qswNzj55KcJa/Iyo6CNPQY+4wEH/SArKJ3e7hX+E2HSmC7lkEQWJ2aVgQ42ZBIzlm0ROTePcmp5lIUjPJ3yMHTSGOmMR06fZxhEt0tiertIjelmFOmC07lF3Pa9rNsXtQ+Mn8Qy7S0LJwzNb671TbRVyOFf5y2P2ELTgI6qattrP/0klnfuwEwQHdqPSdksqVCVdex+nKi/6W72PtpbN7PhTPwK/sFsf2zTgXLd/8BXBCJHNpc4CMBJBN0ZZP30sWai6YkxHxDR9q9QPUSCjZnRe+AYWmc/7/rvvN2wW6NC3gNSp6qxUtmRyMLes/5519QSlyulKNAaGe1gqsQuDSe0B4GgMMvNBfuWWiIrIbYlFOq0/5CZ7yrbDr/xxJc1D99YEPBJBCJEorqh6p0X8tflPsULSPb+nNbP6bjSEszR7RxDgLa9fii5HRwxRho0Em/+E MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d4c52ea2-cdb5-4398-d880-08d814d2b992 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2020 04:30:56.0812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0OCnw2RuRWYlPY+vCA9rk3tSEe2ZcGtWcKZUG56wE/lY9Gr13/msmV4Sv814z4fQGJCSNW+sXCXLp25i5qJVng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4609 Return-Path: eric.dong@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DM6PR11MB327404B914E96EAA4292540CFE990DM6PR11MB3274namp_" --_000_DM6PR11MB327404B914E96EAA4292540CFE990DM6PR11MB3274namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: devel@edk2.groups.io On Behalf Of Brian J. Jo= hnson Sent: Saturday, June 20, 2020 1:29 AM To: devel@edk2.groups.io; Bi, Dandan ; rfc@edk2.group= s.io Cc: Dong, Eric ; Ni, Ray ; Wang, Ji= an J ; Wu, Hao A ; Tan, Ming Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separ= ate NULL class libraries for Memory and serial handlers from MdeModulePkg/U= niversal/StatusCodeHandler modules On 6/18/20 2:01 AM, Dandan Bi wrote: Hi All, REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2816 We plan to separate two kinds of NULL class libraries for Memory and seria= l handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ StatusCodeHan= dlerPei/RuntimeDxe/Smm modules. The benefit we want to gain from this separation is to 1) make the code cl= ear and easy to maintain, 2) make platform flexible to choose any handler l= ibrary they need, and it also can reduce image size since the unused handle= rs can be excluded. If you have any concern or comments for this separation, please let me kno= w. We plan to add new separated NULL class library MemoryStausCodeHandlerLib = and SerialStatusCodeHandlerLib with different phase implementation into Mde= ModulePkg\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 me= et their requirements. MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf { NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHand= lerLib.inf NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHa= ndlerLib.inf ... } MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRunti= meDxe.inf { NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausC= odeHandlerLib.inf NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatu= sCodeHandlerLib.inf ... } MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf { NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCode= HandlerLib.inf NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHa= ndlerLib.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 St= atusCodeHandler modules will call multiple StatusCodeHandlerLib libraries. How about adding StatusCodeHandlerLib support directly to the ReportStatus= CodeRouter modules? Then platforms could omit the StatusCodeHandler module= s if they're only using the open-source code. That sounds like less overhe= ad since fewer modules would be needed Hi Brain, You are right. Current design truly has a lot of layers. The ReportStatusC= odeRouter module provides the register logic and maintain the registered st= atus 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 platfor= m has more than one status code handler drivers' issue. We expect the platf= orm only need one wrapper driver in MdeModulePkg to let the status code han= dler 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> --_000_DM6PR11MB327404B914E96EAA4292540CFE990DM6PR11MB3274namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

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>; r= fc@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@inte= l.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 MdeModu= lePkg/Universal/StatusCodeHandler modules

 

On 6/18/20 2:01 AM, Dand= an Bi wrote:

Hi All,

 

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

 

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 g= ain 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 separ= ated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib wit= h different phase implementation into MdeModulePkg\Library\ directory.

The main tree structure = may like below:

MdeModulePkg\Library

|------MemoryStausCod= eHandlerLib

|------|------ PeiMemory= StausCodeHandlerLib.inf

|------|------ RuntimeDx= eMemoryStatusCodeHandlerLib.inf

|------|------ SmmMemory= StausCodeHandlerLib.inf

|------SerialStatusCo= deHandlerLib

|------|------ PeiSerial= StatusCodeHandlerLib.inf

|------|------ RuntimeDx= eSerialStatusCodeHandlerLib.inf

|------|------ SmmSerial= StatusCodeHandlerLib.inf

 =

 =

We will update existing = platform use cases in edk2 and edk2-platform repo to cover the new NULL cla= ss library to make sure this change doesn’t impact any platform.=

After this separation, S= tatusCodeHandler module usage will like below, and it’s also very fle= xible for platform to cover more handler libraries to meet their requiremen= ts.

MdeModulePkg/Universal/S= tatusCodeHandler/Pei/StatusCodeHandlerPei.inf {

  <LibraryClasse= s>

NULL|= MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib= .inf

NULL|= MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerL= ib.inf

    ̷= 0;

}

 

MdeModulePkg/Universal/S= tatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf  {

  <LibraryClasse= s>

NULL|= MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHan= dlerLib.inf

NULL|= MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeH= andlerLib.inf

    ̷= 0;

}

 

MdeModulePkg/Universal/S= tatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {

  <LibraryClasse= s>

    NULL|= MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib= .inf

NULL|= MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerL= ib.inf

    ̷= 0;

}

 

 

Thanks,

Dandan

 

Dandan,

We'll have a lot of layers of indirection...= .  The ReportStatusCodeRouter modules will call one or more StatusCode= HandlerModules, and the standard StatusCodeHandler modules will call multip= le StatusCodeHandlerLib libraries.

How about adding StatusCodeHandlerLib suppor= t directly to the ReportStatusCodeRouter modules?  Then platforms coul= d 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 ReportStat= usCodeRouter module provides the register logic and maintain the registered= status code handlers. Now the platform may have more than one of drivers u= sed 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

--_000_DM6PR11MB327404B914E96EAA4292540CFE990DM6PR11MB3274namp_--