From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4a::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4CC511A1E3D for ; Mon, 10 Oct 2016 09:23:29 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0289.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 10 Oct 2016 16:23:27 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0659.020; Mon, 10 Oct 2016 16:23:27 +0000 From: "Cohen, Eugene" To: "Kinney, Michael D" , "Gao, Liming" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" Thread-Topic: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Thread-Index: AdIbIt8zDF4zYVg0Qm6BbTDEpt2HcgAA5RyAAARYvtAAAp28gAAI576gAZpdBoAATn70sAABT7uAAACv6eA= Date: Mon, 10 Oct 2016 16:23:27 +0000 Message-ID: References: <9877647c-b348-2a36-9ac0-b520a82260d1@redhat.com> <654a587b-8f79-51ef-8ba9-a29779de46c9@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14B4820B6@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.252.13] x-ms-office365-filtering-correlation-id: 85ebe6a6-e764-4494-b065-08d3f129c44b x-microsoft-exchange-diagnostics: 1; AT5PR84MB0289; 6:O0HK1DUaKx0/8e1Z6L3+HIEv6Ni23kQjhJMOVtta6NOHMF3cCCHPXTfB1qaqNylMqXgXCh76JTo3wb2Ur0sYPN1I5HEjl2nYN2ZVvbc0LuALS4NLUB2rk0hnUP1V4+orF3sdRvUc7qdjnb5S2gDU35HJSM9yKKojcvXerkb82GVgEdt9SSC5C701B4Fs7i/dIvhu07esqijd6yOScxX+cDrmQWdFdXYqWrQN5yIsVc1hlwlcRJTtrt9dp5DTMQ9eDAvihmh5ja7Asd5fA4r4FmH1J4PO6zWS97BbCWJnlHiuZsZslWZruf3ewpizdxAq; 5:FB/FuD4qwLj+gngpeQnIVbCUXMw25u/H5ZIdRgfqsFNJB6hd7DkXyu4BOK1Mtq4zPZmzUY8UbhB770/tcgevdqJ1126yLUH2431bARKVBBBTTCLPc/4fL49zoNwcYjrMFj3XR1+r/ClBPehJX5BxEDzO175Zlq9dmrSKb4etD3k=; 24:LR6UE387CD/EAGenq8fa7E2UD/qlsNSos6l1oDRY6Pnurhp8cQPrwTsH5ZfQT/LYnlX9RgfNCS6CglHtiLVXULoKbSJg3QbGS8a8E9f1PhI=; 7:G/xwVRvuIhEla7oX9mO5E4w8op96vL5JtD5D6UrZrFqd9KSmX0RqY4Fna9/V2BDSecZM/37OIFgg48WZK5YIwTJKpevO/if8GEl5leh5sBTP6mlFWkYI20Oa5de8CYahE+Ytz++Fcp7sUNE0Rv7gVYhPYW9eW6kNFw7TEXCYGOWLh7TvDgaJo2w26eIIYjC8tVgt8i6wr7BDBdyK3I2abed2JLybvSOgtFgc2zTHRuGaoPu3L6gK12jdLDyDXTCBLil81bJ6wC7Acv2wmXu+B8CY8X1OLA62FLwbYnEhPI7rquzMWi2SAc9+4HvsFikrfjx7DAyeXlBpa+RmugrqkN2QqQ4qd63uaKsrf1TnQX4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0289; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AT5PR84MB0289; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0289; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(6602003)(5002640100001)(87936001)(99286002)(33656002)(92566002)(561944003)(5001770100001)(107886002)(189998001)(97736004)(7696004)(86362001)(105586002)(586003)(11100500001)(2950100002)(3846002)(106356001)(102836003)(2906002)(6116002)(5660300001)(66066001)(7736002)(305945005)(74316002)(101416001)(2900100001)(3280700002)(3660700001)(8666005)(8936002)(7846002)(77096005)(76176999)(50986999)(54356999)(9686002)(122556002)(93886004)(8676002)(10400500002)(81156014)(81166006)(68736007)(7059030)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0289; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 16:23:27.6868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0289 Subject: Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services 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: Mon, 10 Oct 2016 16:23:29 -0000 Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mike, > The GUID values for PPIs, DXE Protocols, UEFI Protocols, > and SMM Protocols are unique. Which means if code is written > to work in one phase, you can not share code to another > phase because the GUID values must be changed. My original use case was a protocol definition where both the protocol stru= cture and GUID value are shared across DXE and SMM. I was not aware of the= "GUIDs must be unique" requirement - can you elaborate on this? > The other libs you mentioned have the attribute that the > parameters to the library APIs do not have to be updated as > source code is moved or shared between phase types. This API usage would have to be consistent across phases as well for this p= roposal to be of value. I agree - if the users of the library have to chan= ge the way they call then the library is of little (or maybe even negative)= value. > Given that the source can not be shared, what is gained by > adding a library? The use case is definitely to share the source. In our envisioned use case we would have these two stacks: DXE Driver Library X that uses a "protocol" ProtocolLib (DXE instance) and SMM Driver Library X that uses a "protocol" ProtocolLib (SMM instance) so the value is being able to reuse Library X since all it depends on is a = common protocol. The protocol would need to have absolutely identical usag= e (and in our use case this is true). > Would you recommend using this lib in all module types? I was originally envisioning only DXE and SMM Drivers (and Cores) only. Ji= ewen suggested PEI which I had not considered which could theoretically be = supported so long as a common "protocol" definition was usable across PEI a= nd DXE/SMM which is a situation I have not yet had a need to explore. (I t= hink the semantics of the PEI no-writeable-globals due to Flash XIP drives = differences in design that may make this impractical but I'm not sure.) =20 > Maybe you can share both the proposed library class APIs and > typical usage from different module types. Yes, I think I need to make it a little more real at this point. Action It= em Taken. Eugene