From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 60282803B2 for ; Fri, 24 Mar 2017 10:09:14 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AB57320B05; Fri, 24 Mar 2017 17:09:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AB57320B05 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AB57320B05 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-209.phx2.redhat.com [10.3.116.209]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7D881189C3; Fri, 24 Mar 2017 17:09:12 +0000 (UTC) To: "Zeng, Star" , Ard Biesheuvel , "Kinney, Michael D" , "afish@apple.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> Cc: "Tian, Feng" , edk2-devel-01 , Leif Lindholm , "Gao, Liming" From: Laszlo Ersek Message-ID: <5b2c0152-85fe-db6b-e173-0e4b0891e0f2@redhat.com> Date: Fri, 24 Mar 2017 18:09:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B84CA03@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 24 Mar 2017 17:09:14 +0000 (UTC) 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: Fri, 24 Mar 2017 17:09:14 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 all 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 = 0x00010005 > BASE_NAME = DepexLib > FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX > MODULE_TYPE = BASE > VERSION_STRING = 1.0 > LIBRARY_CLASS = 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 [Depex] 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 = 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=443 -- for BaseTools, https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- 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 Has 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 instance 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 dependencies) > > 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 >