From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org 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 40220211E0940 for ; Wed, 20 Mar 2019 10:47:32 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ED48330FE5B7; Wed, 20 Mar 2019 17:47:31 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-169.rdu2.redhat.com [10.10.120.169]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83BEE60852; Wed, 20 Mar 2019 17:47:29 +0000 (UTC) To: Heyi Guo , Ard Biesheuvel Cc: Peter Maydell , Hao Wu , "edk2-devel@lists.01.org" , Julien Grall , wanghaibin 00208455 References: <1551341112-21645-1-git-send-email-guoheyi@huawei.com> <27394137-8c32-4f8a-c029-5fc883a2cce0@huawei.com> <69336094-c1c0-b978-7fe7-6a585faedda6@huawei.com> <8b2a9fcd-fb0d-6432-4481-e05d08816332@redhat.com> <1e39908c-3f26-7b87-8bd3-8ae04221cf58@huawei.com> From: Laszlo Ersek Message-ID: Date: Wed, 20 Mar 2019 18:47:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1e39908c-3f26-7b87-8bd3-8ae04221cf58@huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Wed, 20 Mar 2019 17:47:32 +0000 (UTC) Subject: Re: [RFC 0/3] Enable runtime serial debug for ArmVirtQemu X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 17:47:33 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/20/19 13:16, Heyi Guo wrote: > > > On 2019/3/20 17:55, Laszlo Ersek wrote: >> If we don't have to flatten a ridiculous amount of other library code >> into the RuntimePrepare() function, I think such flattening would be a >> viable approach. We've run into this constructor loop several times >> before, and -- if I remember correctly anyway! -- one approach has been >> to declare SerialPortLib the "lowest level abstraction", and make the >> affected lib instance self-contained. > In my RFC, we need to use gDS which is from > DxeServicesTableLib->EfiGetSystemConfigurationTable()->UefiLib, so that > we need to flatten EfiGetSystemConfigurationTable(). I think that's acceptable. > And > gDS->SetMemorySpaceAttributes() actually relies on > gEfiCpuArchProtocolGuid or it will return EFI_NOT_AVAILABLE_YET. This is a valid dependency (even the PI spec spells it out). The way to deal with it is to add gEfiCpuArchProtocolGuid to the DEPEX section of the INF file -- this is possible for INF files of library instances as well, but you have to be careful about module types. Please see the INF spec on that. Once you do this, modules linked against the lib instance will inherit the lib instance's DEPEX, and "and it" together with the rest of their DEPEX. IOW using the library will delay the containing driver module until the CPU Arch protocol is available in the protocol database. Then the constructor can rely on the related DXE services. Thanks Laszlo