From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8D32180451 for ; Fri, 24 Mar 2017 10:11:30 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id w124so14608428itb.1 for ; Fri, 24 Mar 2017 10:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QbW8MNmyttgex4DjWOIxtK6rIb8jYWeiSwpO4ZSAvF8=; b=LsXAUnLNYLqbSfv8WfoG9BgS2eLDiP//uVHUeLzhxx7sDqQHm2SOFG1tMNy36B9nT5 8FDzwZC5E9Q+STp+fhUHYesSS0KS4xDA8paoDaKWRhVmVcOmZxCUSs6pxDtUsSg3hLYV AFPMGxc07vbmcyfQbFlm4WcjxzlaTlGJLrBZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QbW8MNmyttgex4DjWOIxtK6rIb8jYWeiSwpO4ZSAvF8=; b=OAMEJK2HDw5gB0qNosbCdLfrGGx8opiVpzMtCdVl3yUojwTl5c40IXzHaOijyPbTy9 5tAPcPHWz3dnZqjpucERpYymsDl4djRTA40rg1xpTf6OyRlKkEPuJa++e47heYpRoQSf CzcrAnd5hqAjUl9MITVmEIpD/S4NzD3y+cXp8H8cT/2045EXNG25KhnNOKkgZzJd8knM KnfII+p6mlzQCskbdNx1jRmqX6E03a/zawIX4iKzU8kRVEkTt7eM2E5wG0/L5Je8lq47 stosQsJ6DKgBoyiWojf0GE8d3AqT+gSgbrP7ZRpHMQ2UGYcajA4h0OCFnh0FewLQ0hSY l/YQ== X-Gm-Message-State: AFeK/H2rR+SRQJUZ3kCRWbdiSG+V3LGdTvRWKZ16OQukpv4An+FQG8RXVQV/yePLecdfKlTTGrw91RbYSI/Z76AU X-Received: by 10.107.168.21 with SMTP id r21mr8807043ioe.45.1490375489116; Fri, 24 Mar 2017 10:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Fri, 24 Mar 2017 10:11:28 -0700 (PDT) In-Reply-To: <2e614ee4-23db-27d8-c502-f37f92f471b1@redhat.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> <2e614ee4-23db-27d8-c502-f37f92f471b1@redhat.com> From: Ard Biesheuvel Date: Fri, 24 Mar 2017 17:11:28 +0000 Message-ID: To: Laszlo Ersek Cc: "Zeng, Star" , "Kinney, Michael D" , "afish@apple.com" , "Tian, Feng" , edk2-devel-01 , Leif Lindholm , "Gao, Liming" 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:11:30 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24 March 2017 at 17:10, Laszlo Ersek wrote: > 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 support= ed or not. >>> Some platforms may dynamically determine whether SMBIOS should be suppo= rted or not. >>> Some platforms may dynamically determine whether HII should be supporte= d 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 =3D 0x00010005 >>> BASE_NAME =3D DepexLib >>> FILE_GUID =3D XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX= XX >>> 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 [De= pex] 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 gEdki= iPlatformHasAcpiGuid instead of gEdkiiPlatformHasAcpiProtocolGuid and add t= he GUID into [Guids] section of MdeModulePkg.dec? As Platform can install g= EdkiiPlatformHasAcpiGuid PPI to control PEIM and install gEdkiiPlatformHasA= cpiGuid PROTOCOL to control DRIVER. And another, no need to add a include f= ile 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 dec= lare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib could be= finally added into core package MdeModulePkg or even MdePkg (I prefer). Be= fore that, how about implementing the PlatformHasAcpiLib in none core packa= ge? >>> >> >> 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. > Ack