From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 5439D21BC6A7F for ; Sun, 26 Mar 2017 19:42:39 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 26 Mar 2017 19:42:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,229,1486454400"; d="scan'208";a="948444241" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga003.jf.intel.com with ESMTP; 26 Mar 2017 19:42:38 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 26 Mar 2017 19:42:38 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 26 Mar 2017 19:42:38 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.212]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.224]) with mapi id 14.03.0248.002; Mon, 27 Mar 2017 10:42:36 +0800 From: "Gao, Liming" To: Laszlo Ersek , "Zeng, Star" , "Ard Biesheuvel" , "Kinney, Michael D" , "afish@apple.com" CC: "Tian, Feng" , edk2-devel-01 , Leif Lindholm Thread-Topic: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library Thread-Index: AQHSn1/GB2XPIHVB6UCkCvBSwDIEcaGaK/cAgAZJkQCAALLrAIAAfQMAgAE3iQCAAODaAIAER7gA Date: Mon, 27 Mar 2017 02:42:35 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D702AE8@shsmsx102.ccr.corp.intel.com> References: <20170317204731.31488-1-lersek@redhat.com> <20170317204731.31488-6-lersek@redhat.com> <20170318150041.GL16034@bivouac.eciton.net> <1bc7b29c-7a71-86cb-adce-5a14de129c63@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B8377AB@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B84CA03@shsmsx102.ccr.corp.intel.com> <5b2c0152-85fe-db6b-e173-0e4b0891e0f2@redhat.com> In-Reply-To: <5b2c0152-85fe-db6b-e173-0e4b0891e0f2@redhat.com> 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: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 02:42:39 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo: On GUID header file, some header file are here, because they are added be= fore BaseTools supports it. Now, we allow not to add header file if the hea= der file only has GUID value definition.=20 On GUID C MACRO, we suggest to use GuidCName in every C source code. So, = we don't suggest to add it. As you know, some existing header files have G= uidCName and GUID Macro. Now, we have no plan to clean up the existing one.= But, we expect new added file follows this rule.=20 Thanks Liming >-----Original Message----- >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >Laszlo Ersek >Sent: Saturday, March 25, 2017 1:09 AM >To: Zeng, Star ; Ard Biesheuvel >; Kinney, Michael D >; afish@apple.com >Cc: Tian, Feng ; Gao, Liming ; >edk2-devel-01 ; Leif Lindholm > >Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has >ACPI Protocol, and plug-in library > >On 03/24/17 04:44, Zeng, Star wrote: >> I just think it seems a generic problem. >> Some platforms may dynamically determine whether ACPI should be >supported or not. >> Some platforms may dynamically determine whether SMBIOS should be >supported or not. >> Some platforms may dynamically determine whether HII should be >supported or not. >> ... >> >> We are thinking whether we can have a generic NULL instance to support a= ll >this kind of cases, for example: >> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD >point to a depex GUID. >> 2. Implement a NULL instance DepexLib. >> [Defines] >> INF_VERSION =3D 0x00010005 >> BASE_NAME =3D DepexLib >> FILE_GUID =3D XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX= X >> MODULE_TYPE =3D BASE >> VERSION_STRING =3D 1.0 >> LIBRARY_CLASS =3D NULL >> >> [Sources] >> DepexLib.c >> >> [Packages] >> XXXPkg/XXXPkg.dec >> >> [Depex] >> PcdDepexGuid >> >> 3. Link NULL instance and configure PCD in dsc. >> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf { >> >> NULL|XXXPkg/Library/DepexLib/DepexLib.inf >> >> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid >> } >> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf { >> >> NULL|XXXPkg/Library/DepexLib/DepexLib.inf >> >> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid >> } >> >> But current BaseTools does not support the syntax to declare PCD in [Dep= ex] >section of inf yet. >> >> Based on the statements above, I have below comments. > >> 1. I agree to add the GUID into MdeModulePkg, but how about using >> gEdkiiPlatformHasAcpiGuid instead of >> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids] >> section of MdeModulePkg.dec? As Platform can install >> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install >> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER. > >Sounds reasonable, I'll do this. > >> And another, no >> need to add a include file PlatformHasAcpi.h as BaseTools supports to >> add the GUID definitions to AutoGen files from package dec. > >I disagree with this. I mean, I *personally* wouldn't mind, but this >would be inconsistent with existing MdeModulePkg practice. For example, >see > >MdeModulePkg/Include/Guid/TtyTerm.h > >Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data >structures associated with it; the header file only has an extern >declaration, and -- importantly -- an array initializer macro called >EFI_TTY_TERM_GUID, which can be used in the following syntax: > >STATIC CONST EFI_GUID mThisIsMyGuid =3D EFI_TTY_TERM_GUID; > >So, I think that the GUID header file is required. I will add it in v3. > >Once we generalize this idea to the design that you laid out above, we >can perhaps eliminate the header file. But, for now, I think we should >remain consistent with other MdeModulePkg GUID definitions. > >> 2. You can file bugzilla bug to request BaseTools syntax support to >> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib >> could be finally added into core package MdeModulePkg or even MdePkg >> (I prefer). > >I filed: > >https://bugzilla.tianocore.org/show_bug.cgi?id=3D443 -- for BaseTools, >https://bugzilla.tianocore.org/show_bug.cgi?id=3D444 -- for the INF spec > >> Before that, how about implementing the >> PlatformHasAcpiLib in none core package? > >Works for me; I'll split that part off and keep it under ArmPkg. > >Thanks >Laszlo > >> >> >> Thanks, >> Star >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >Ard Biesheuvel >> Sent: Thursday, March 23, 2017 5:09 PM >> To: Zeng, Star ; Kinney, Michael D >; afish@apple.com >> Cc: Tian, Feng ; Laszlo Ersek ; >edk2-devel-01 ; Leif Lindholm > >> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Ha= s >ACPI Protocol, and plug-in library >> >> On 23 March 2017 at 01:41, Zeng, Star wrote: >>> I prefer to do not include the protocol definition and the library inst= ance >into MdeModulePkg at this moment until they need to be used by multiple >platforms/archs. >>> >> >> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any >architecture) that ACPI is mandatory. Given that EDK2 is the reference >platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is >unreasonable to have lots and lots of PC quirks (i.e., allocations below 4= GB) in >MdeModulePkg, but then disallow a clean approach to make ACPI selectable, >in a way that is true to the spirit of PI (i.e., using protocol dependenci= es) >> >> So I think at least the protocol definitions belong in MdeModulePkg. >> >> Thanks, >> Ard. >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> > >_______________________________________________ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel