From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 8F26C80388 for ; Fri, 24 Mar 2017 00:15:49 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b140so11760765iof.1 for ; Fri, 24 Mar 2017 00:15:49 -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=aWJ12nyvvRPEvzNVYHvkE+iLCZPwyiFBRGLWginoDj4=; b=YQB8Xouk+21vFhh+3gU4MP9zXexgJDmF9mvJlgBzm4i2Jj7cDJJ4QQxoVBl1eKk81m 95dgu9ofy+SfwyIYJrHp1cc3ehd0nsCdj4KwCSY0zV9HnlIAm16Nrztn9CCyx1v+RVwy 1mVvVAjqx3phh/8cMzXLARyxdmVkufLOhHg1A= 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=aWJ12nyvvRPEvzNVYHvkE+iLCZPwyiFBRGLWginoDj4=; b=WrfEwb9CZ41h0WMYowoD3DteEb9NH9/xZED5S+OXw/YepPsMAdIYPMwznkcI4kphK/ ClinMRX/DPBhj18VeEwwxLjARa6jXA3GLy21hUYPCsj+NEGDX/xiAQnYyhQsQlSL+Jrw RzNoSj7fNEvKxUHoK4OT6iNiRtSlVVla+auMdi/iMdbC4nYgoD1MKFp0txRuHNAB3inY f4UAGBC5WFns1QQQjxO0UlxkZIekEg7yXMZnVO0xhz199eYvDwSs5Az1bq7FqU8WmXhh FPjDcEH4dkoU56h0jGcI/8I5uJURvwkXvmSGv3epOb0OGSfikP94FVqAPKeCX/Zou5Wq x7EA== X-Gm-Message-State: AFeK/H1wZEceE6lehDPkw+cUZJAOkp5W1NHKr+kb6Bj3WuYJuh0CVEDeeg0gpGiP1gy3y0D8wcrrOJkxrV9j6FNq X-Received: by 10.107.168.21 with SMTP id r21mr6448235ioe.45.1490339748826; Fri, 24 Mar 2017 00:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Fri, 24 Mar 2017 00:15:48 -0700 (PDT) In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B84CA03@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> From: Ard Biesheuvel Date: Fri, 24 Mar 2017 07:15:48 +0000 Message-ID: To: "Zeng, Star" Cc: "Kinney, Michael D" , "afish@apple.com" , "Tian, Feng" , Laszlo Ersek , 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 07:15:49 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 support= ed 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 al= l this kind of cases, for example: > 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD p= oint 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-XXXXXXXXXXXX > 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 [Depe= x] 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 gEdkiiP= latformHasAcpiGuid instead of gEdkiiPlatformHasAcpiProtocolGuid and add the= GUID into [Guids] section of MdeModulePkg.dec? As Platform can install gEd= kiiPlatformHasAcpiGuid PPI to control PEIM and install gEdkiiPlatformHasAcp= iGuid PROTOCOL to control DRIVER. And another, no need to add a include fil= e PlatformHasAcpi.h as BaseTools supports to add the GUID definitions to Au= toGen files from package dec. > 2. You can file bugzilla bug to request BaseTools syntax support to decla= re PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib could be f= inally added into core package MdeModulePkg or even MdePkg (I prefer). Befo= re 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. Thanks, Ard.