From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web12.488.1584026913587688684 for ; Thu, 12 Mar 2020 08:28:33 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.43, mailfrom: isaac.w.oram@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2020 08:28:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,545,1574150400"; d="scan'208";a="443973840" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga006.fm.intel.com with ESMTP; 12 Mar 2020 08:28:33 -0700 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 12 Mar 2020 08:28:32 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.140]) by ORSMSX154.amr.corp.intel.com ([169.254.11.196]) with mapi id 14.03.0439.000; Thu, 12 Mar 2020 08:28:32 -0700 From: "Oram, Isaac W" To: Ray Ni , "devel@edk2.groups.io" CC: "Ni, Ray" , "Dong, Eric" , "Chan, Amy" , "Chaganty, Rangasai V" Subject: Re: [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" for features Thread-Topic: [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" for features Thread-Index: AQHV+GuiAzzqjROLBkGrS/FWSmrAN6hE/Ihw Date: Thu, 12 Mar 2020 15:28:32 +0000 Message-ID: <3155A53C14BABF45A364D10949B7414C973CEA9F@ORSMSX114.amr.corp.intel.com> References: <20200312124117.288336-1-niruiyu@users.noreply.github.com> In-Reply-To: <20200312124117.288336-1-niruiyu@users.noreply.github.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-originating-ip: [10.22.254.140] MIME-Version: 1.0 Return-Path: isaac.w.oram@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, I don't think that this is a desirable rule. I want to create feature packages that bundle frequently used together exis= ting capabilities. See the NetworkFeaturePkg for an example. I also want = to make feature packages for the USB stack, debug capabilities, and the lik= e that are often aggregations of existing modules. The Minimum Platform Architecture spec targets advanced features that are e= asy to enable for relatively inexperienced developers. One way of doing th= at is to leverage the UEFI PI arch and its binary component support feature= s. The Minimum Platform Architecture aims to use this to enable a use case= leveraging Firmware Volumes that looks like: 1: Build NetworkFeaturePkg (this produces an FV, customized via PCD and/or= static libraries as needed) 2: Load FV (from shell, by injecting into an existing image using FMMT, Fi= ano, etc) 3: Use network features and functionality The model where the only way people extend a UEFI firmware image is by rebu= ilding a complete solution needs to end. It is a misuse of the architectur= e in my estimation. We have not had much success with fine granularity com= ponent binary use, i.e. individual PEIM and drivers. Perhaps there is too = much expertise needed. Minimum Platform Architecture and Advanced Features= aim to improve this by enabling larger granularity binary components that = require less UEFI knowledge to use effectively. I recognize that there is a competing vision that wants to make many small = feature packages that are easy to build in or out based on simple PCD featu= re flags. As that may improve developer's experience, it is not something = I am strongly contesting. However, I just don't see it as any different th= an MdeModulePkg. It is the same strategy, just using packages to organize = instead of directories. The other consideration should include that we have a lot of existing users= . I don't want to move existing code around to make usable features. If w= e move existing code to create the feature in the first place, we affect al= l the existing users, often for no immediate benefit. If features become s= uccessful and widely used, then is a good time to refactor the code. The d= ifference is that at that time, the change is essentially behind an abstrac= tion and so the change doesn't cause as much pointless work. =20 Regards, Isaac -----Original Message----- From: Ray Ni =20 Sent: Thursday, March 12, 2020 5:41 AM To: devel@edk2.groups.io Cc: Ni, Ray ; Dong, Eric ; Chan, Amy= ; Chaganty, Rangasai V = ; Oram, Isaac W Subject: [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" f= or features Today's document doesn't forbidden creation of a feature package with only = interfaces and no code to implement the interfaces. Such feature package is= useless. Signed-off-by: Ray Ni Cc: Eric Dong Cc: Amy Chan Cc: Rangasai V Chaganty Cc: Isaac W Oram --- Features/Intel/Readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Features/Intel/Readme.md b/Features/Intel/Readme.md index 9729= f90a41..f0923e3d56 100644 --- a/Features/Intel/Readme.md +++ b/Features/Intel/Readme.md @@ -18,7 +18,7 @@ document as needed. Advanced features should be: * _Cohesive_, the feature should not contain any functionality unrelated t= o the feature. * _Complete_, the feature must have a complete design that minimizes depen= dencies. A feature package cannot directly - depend on another feature package. + depend on another feature package. A feature package must contain module= (s) to implement the feature interfaces. * _Easy to Integrate_, the feature should expose well-defined software int= erfaces to use and configure the feature. * It should also present a set of simple and well-documented standard ED= K II configuration options such as PCDs to configure the feature. -- 2.21.0.windows.1