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 743CC80294 for ; Fri, 24 Mar 2017 10:10:54 -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 CD0E3C04B31F; Fri, 24 Mar 2017 17:10:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CD0E3C04B31F Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com CD0E3C04B31F 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 B40C219146; Fri, 24 Mar 2017 17:10:52 +0000 (UTC) To: Ard Biesheuvel , "Zeng, Star" 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: "Kinney, Michael D" , "afish@apple.com" , "Tian, Feng" , edk2-devel-01 , Leif Lindholm , "Gao, Liming" From: Laszlo Ersek Message-ID: <2e614ee4-23db-27d8-c502-f37f92f471b1@redhat.com> Date: Fri, 24 Mar 2017 18:10:50 +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: 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.31]); Fri, 24 Mar 2017 17:10:55 +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:10:54 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/24/17 08:15, Ard Biesheuvel wrote: > On 24 March 2017 at 03: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. 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. >> 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). Before that, how about implementing the PlatformHasAcpiLib in none core package? >> > > Hello Star, > > Thanks for taking the time to think about this. It is much appreciated. > > I like the generic approach for dynamic dependencies. The more > architectures are supported in UEFI, the more often we are likely to > see the need for such things. > > I will let Laszlo speak for himself, as the author of the patches, but > I am perfectly fine with > a) the outline above of how we address this in the long term, > b) taking anything we need for the short term into ArmPkg, and move it > to MdeModulePkg and/or MdePkg later. To confirm what Leif requested and what we've since discussed on IRC: since the Has-Acpi GUID is now going under MdeModulePkg, I'll move the Has-DeviceTree GUID under EmbeddedPkg. Thanks Laszlo