From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.24; helo=mga09.intel.com; envelope-from=liming.gao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 B6D8B209574FD for ; Tue, 27 Feb 2018 03:15:34 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 03:21:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,400,1515484800"; d="scan'208";a="207398550" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga006.fm.intel.com with ESMTP; 27 Feb 2018 03:21:40 -0800 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Feb 2018 03:21:40 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Feb 2018 03:21:40 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.125]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.116]) with mapi id 14.03.0319.002; Tue, 27 Feb 2018 19:21:37 +0800 From: "Gao, Liming" To: Pankaj Bansal , "Kinney, Michael D" , Laszlo Ersek , "edk2-devel@lists.01.org" Thread-Topic: [edk2] [RFC] Add Platform Include path in modules Thread-Index: AQHTrstLnAIY2cMyokKsOaQoNIhl9aO1xxEAgAA1zQCAAFPdgIAAGS0AgADupwCAAMNUsA== Date: Tue, 27 Feb 2018 11:21:37 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E1D4100@SHSMSX104.ccr.corp.intel.com> References: <1519626521-15902-1-git-send-email-pankaj.bansal@nxp.com> <76e5168a-e3c2-97bb-dac1-22ffc212c7ee@redhat.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [RFC] Add Platform Include path in modules X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 11:15:36 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 For the first one, the same PCD can be configured to the different value = for the different SkuId.=20 Here is wiki on structure pcd enable step and examples.=20 https://github.com/lgao4/edk2/wiki/StructurePcd-Enable-Steps TestPkg in https://github.com/lgao4/edk2/tree/UDK2018 has the sample case w= ith structure pcd.=20 Thanks Liming >-----Original Message----- >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >Pankaj Bansal >Sent: Tuesday, February 27, 2018 3:40 PM >To: Kinney, Michael D ; Laszlo Ersek >; edk2-devel@lists.01.org >Cc: Gao, Liming >Subject: Re: [edk2] [RFC] Add Platform Include path in modules > >Hi Laszlo/Michael, > >Thanks for your feedback on this proposal. >I looked at the structured PCDs and UEFI Platform Initialization Distribut= ion >Packaging Specification. >Here is my take on these. > >1. structured PCDs are good if we want to declare single complex structure= . > But consider a case where I want to keep device information in structu= re. >(e.g. hardware settings, limitations etc) > And we may want to tweak this information based on platform revision >being used. > And different platforms can have different number of such devices. > In this case, when we want to add a new platform, we might need to >introduce new PCDs in .dec files, which will not be needed for others. > I don't know, will this even increase the PCD database size for existi= ng >platforms or not ? > >2. To mitigate the "hidden" dependency of a module on platform, we can >explicitly declare this dependency in module inf file. > I am thinking something like gEfiCallerIdGuid, i.e. module can declar= e that >that platform building(using) the module, supply this information. > >3. Using Libraries and Protocols can also solve such use cases. I just fel= t that it's >less cumbersome to use include files, and it also avoids code replication. > Anyway, this is just my suggestion to have such mechanism in edk2 buil= d >process. I am more than happy to stick to platform libraries. > >Thanks & Regards, >Pankaj Bansal > >> -----Original Message----- >> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] >> Sent: Monday, February 26, 2018 10:56 PM >> To: Laszlo Ersek ; Pankaj Bansal >> ; edk2-devel@lists.01.org; Kinney, Michael D >> >> Cc: Gao, Liming >> Subject: RE: [edk2] [RFC] Add Platform Include path in modules >> >> Hi Pankaj, >> >> I agree with Laszlo that you should evaluate use of PCDs. There are a f= ew >> methods for a driver to use platform specific values/behavior. These ar= e: >> >> * PCDs >> * Library class/Library Instance >> * Protocol/PPI >> >> One issue with the proposal is that it adds a hidden dependency to modul= es. >> An EDK II INF file describes the external interfaces of a module along w= ith >> produces/consumes usage. This information is aligned with the XML >schema >> that is documented in the UEFI Platform Initialization Distribution Pack= aging >> Specification. >> >> >> >https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fuefi. >> >org%2Fspecifications&data=3D02%7C01%7Cpankaj.bansal%40nxp.com%7C96c4 >> 2dd7271d449d56e908d57d3df2d4%7C686ea1d3bc2b4c6fa92cd99c5c301635 >> %7C0%7C0%7C636552627376357192&sdata=3DsS7KT3haANF5TLHSeRGjIQHnLQ >> BtnTDLIZWntUhsk78%3D&reserved=3D0 >> >> If two modules have the same GUID/Version, then the external interfaces >to >> those two modules are expected to be identical. >> With your proposal, two modules built for 2 different platforms would ha= ve >> the same GUID/Version but would not have the same external interfaces >> because a hidden dependency on a platform package was added. >> >> If a module really needs to use content from a platform package, then a >new >> copy of the module should be created with a new GUID/Version and the >> platform package added to the [Packages] section. The other option is t= o >use >> one of the supported interfaces (PCDs, Lib, Protocol, PPI). >> >> Please let us know if any of these exiting methods do not work for your = use >> case. >> >> Thanks, >> >> Mike >> >> > -----Original Message----- >> > From: Laszlo Ersek [mailto:lersek@redhat.com] >> > Sent: Monday, February 26, 2018 7:55 AM >> > To: Pankaj Bansal ; Kinney, Michael D >> > ; edk2- devel@lists.01.org >> > Cc: Gao, Liming >> > Subject: Re: [edk2] [RFC] Add Platform Include path in modules >> > >> > On 02/26/18 11:55, Pankaj Bansal wrote: >> > > Hi, >> > > >> > > Consider a simple driver which needs that some data >> > structures be >> > > filled by the Platform, which is using the driver. >> > > >> > > Driver.c #include >> > > >> > > Struct a =3D platformVal; >> > > >> > > We can define platformVal in Platform.h, which would >> > be unique to the >> > > platform being built. This Platform.h can be placed in >> > include >> > > directories, whose path would be defined in >> > Platform.dec file. >> > > >> > > Now, whenever we build driver for each unique >> > platform, we need not >> > > to mention Platform.dec file in driver.inf [packages] >> > section. We can >> > > append Platform.dec include paths to each driver. i.e. >> > look for the >> > > include files in [packages] section as well as in >> > Platform include >> > > directories. >> > > >> > > For this, I am looking for Platform.dec file in same >> > directory as >> > > Platform.dsc and using same name as Platform.dsc >> > > >> > > We can refine this change further. i.e. add Platform >> > include >> > > directories to driver's include paths based on some >> > condition in >> > > driver.inf file. >> > >> > (Apologies in advance if I failed to grasp the use >> > case.) >> > >> > If I understand correctly, you have multiple platforms (defined by DSC >> > and FDF files), and you build a given driver for several of these >> > platforms, separately. And, when building the driver for the separate >> > platforms, you'd like the driver to get different initializers for >> > various static (global) structure variables. >> > >> > Have you tried the structured PCD format? I think that could cover >> > your use case. >> > >> > Unfortunately I couldn't find anything about structured PCDs in the >> > edk2 specs, but there are several BZ references in the following >> > mailing list >> > message: >> > >> > [edk2] [Patch 00/14] Enable Structure PCD support in >> > edk2 >> > >> > >> >https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fmid. >> > mail-archive.com%2F1512140335-6932-1-git-send- >> &data=3D02%7C01%7Cpankaj.b >> > >> ansal%40nxp.com%7C96c42dd7271d449d56e908d57d3df2d4%7C686ea1d3b >> c2b4c6fa >> > >> 92cd99c5c301635%7C0%7C0%7C636552627376357192&sdata=3DiR50v%2F4Jg% >> 2BZQh7P >> > 1LB1bxeCryTangpA1SyVCwCEQW2U%3D&reserved=3D0 >> > email-liming.gao@intel.com >> > >> > Thanks >> > Laszlo >_______________________________________________ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel