From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web09.8505.1578653064268496679 for ; Fri, 10 Jan 2020 02:44:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LOnTFTs7; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578653063; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lUg5NhObPUo06BgFmbXSuZoJIWZdF0WNcxNX5oPjASQ=; b=LOnTFTs7A8+OUUusvDp70VaKxDkgnx9hYFKtWGVfkjQtxvemcMTLqbi9LKEqkwgymhDC5R A/6/o7MHmW4foorLzwhNcJrUochHvoHFdpINQFCpBucLMItH/8uc6EDFHNN217TXb9hekE jJT2z9xJrs/YH0V6mGouzeFTHFo4dio= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-JHqzm4uuMR6EkiVVrq0E9Q-1; Fri, 10 Jan 2020 05:44:20 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 98EEE801E67; Fri, 10 Jan 2020 10:44:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-179.ams2.redhat.com [10.36.116.179]) by smtp.corp.redhat.com (Postfix) with ESMTP id CA0BE7BA51; Fri, 10 Jan 2020 10:44:16 +0000 (UTC) Subject: Re: [edk2-devel] [RFC] BZ 2298 MdePkg/DevicePathLib merger or not To: devel@edk2.groups.io, ray.ni@intel.com, "Gao, Zhichao" , "'rfc@edk2.groups.io'" Cc: "Gao, Liming" , "Kinney, Michael D" , "vit9696@protonmail.com" References: <3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFA@SHSMSX101.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C3E8084@SHSMSX104.ccr.corp.intel.com> <3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08@SHSMSX101.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C3E846D@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 10 Jan 2020 11:44:15 +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: <734D49CCEBEEF84792F5B80ED585239D5C3E846D@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: JHqzm4uuMR6EkiVVrq0E9Q-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 01/10/20 10:39, Ni, Ray wrote: > So, the impact is every platform DSC needs to be updated to reference the correct path of the UefiDevicePath lib after your merge. I agree -- I expect that most if not all platform DSC files will need updates. That's because the most frugal approach for a platform is to use the self-contained UefiDevicePathLib instance only in very early DXE phase modules (DXE core, and DevicePathDxe itself), and use the thin UefiDevicePathLibDevicePathProtocol instance in all other DXE modules. See e.g. Ray's OvmfPkg commit 5c3481b0b611 ("OvmfPkg: Use the new DevicePathLib for all platforms", 2013-08-19). See also ArmVirtPkg commit f9dff9028950 ("ArmVirtPkg: use protocol-based DevicePathLib instance for most DXE modules", 2018-04-30), which provides more explanation. Thanks, Laszlo > Let's wait for at least 2 weeks for feedbacks. > > Thanks, > Ray > > From: Gao, Zhichao > Sent: Friday, January 10, 2020 3:47 PM > To: Ni, Ray ; devel@edk2.groups.io; 'rfc@edk2.groups.io' > Cc: Gao, Liming ; Kinney, Michael D ; vit9696@protonmail.com > Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not > > Ray, > I prefer to merge these two lib instance into one folder and remove the duplicated code. > I can change all the required change in open source repo. But not sure how many close source platforms would be affected. > This action should make all the close platform owners aware of it and changing their platform code to consume the new lib instance. > > #2: OK. That makes sense to consume the new device path node if appear. > > Thanks, > Zhichao > > From: Ni, Ray > Sent: Friday, January 10, 2020 3:36 PM > To: Gao, Zhichao >; devel@edk2.groups.io; 'rfc@edk2.groups.io' > > Cc: Gao, Liming >; Kinney, Michael D >; vit9696@protonmail.com > Subject: RE: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not > > Zhichao, > What's your recommendation regarding this? > > Back to your 2nd question, drivers/applications consuming UefiDevicePathLibOptionalDevicePathProtocol > can firstly use the firmware built-in from-text and to-text conversion, then use its own conversion logic if > the firmware doesn't contain built-in from-text or to-text conversion. > Considering a case that an application is released in year 2015, it can recognize the new device path node > introduced after 2015 in a new system. > > Thanks, > Ray > > From: Gao, Zhichao > > Sent: Friday, January 10, 2020 11:04 AM > To: devel@edk2.groups.io; 'rfc@edk2.groups.io' > > Cc: Gao, Liming >; Kinney, Michael D >; vit9696@protonmail.com; Ni, Ray > > Subject: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not > > HI all, > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298 > In the MdePkg, there are two folder for the DevicePathLib: > > 1. MdePkg\Library\UefiDevicePathLib > 2. MdePkg\Library\UefiDevicePathLibDevicePathProtocol > > UefiDevicePathLibDevicePathProtocol is created to use the protocol to reduce the driver size which consume the DevicePathLib. > But it has duplicate code with #1. So I want to merge these two folder into one. But many platform implementations consume #2. > If we merge #2 into #1, there might be a lot of platform changes for both close source and open source. > Can anyone give me some suggestions about this? Do we have a progress to retire some implementation in the edk2 repor? > > There is another question about MdePkg\Library\UefiDevicePathLib\UefiDevicePathLibOptionalDevicePathProtocol.inf. > This one implements the interface to choose the protocol first, then change to local implementation if no protocol is available. > It requires a fix and it is already sent to the community. But what's the purpose? > Local implementation, i.e. MdePkg\Library\UefiDevicePathLib\ UefiDevicePathLib.inf, can make sure its usable. And it can't reduce the driver size. If it is useless, can we directly remove it? > > Thanks, > Zhichao > > > > >