From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=45.249.212.32; helo=huawei.com; envelope-from=guoheyi@huawei.com; receiver=edk2-devel@lists.01.org Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) (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 0E7B9211E2BF0 for ; Wed, 20 Mar 2019 20:24:05 -0700 (PDT) Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id C4B33FAAA06CD181BD33; Thu, 21 Mar 2019 11:24:02 +0800 (CST) Received: from [127.0.0.1] (10.177.31.55) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.408.0; Thu, 21 Mar 2019 11:23:52 +0800 To: Laszlo Ersek , Ard Biesheuvel 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> CC: Peter Maydell , Hao Wu , "edk2-devel@lists.01.org" , Julien Grall , wanghaibin 00208455 From: Heyi Guo Message-ID: <3682377d-3767-cfd9-09c1-38e79da005d3@huawei.com> Date: Thu, 21 Mar 2019 11:23:51 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.177.31.55] X-CFilter-Loop: Reflected 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: Thu, 21 Mar 2019 03:24:06 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 2019/3/21 1:47, Laszlo Ersek wrote: > 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. Yes, one is VariableRuntimeDxe, whose DEPEX is TRUE right now, but I think it is acceptable. I can take a try for the above proposal. Thanks, Heyi > > Then the constructor can rely on the related DXE services. > > Thanks > Laszlo > > . >