From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mx.groups.io with SMTP id smtpd.web10.5054.1578625413996239058 for ; Thu, 09 Jan 2020 19:03:34 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: zhichao.gao@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2020 19:03:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,415,1571727600"; d="scan'208,217";a="371484252" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga004.jf.intel.com with ESMTP; 09 Jan 2020 19:03:33 -0800 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 19:03:32 -0800 Received: from shsmsx105.ccr.corp.intel.com (10.239.4.158) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 19:03:32 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.30]) by SHSMSX105.ccr.corp.intel.com ([169.254.11.28]) with mapi id 14.03.0439.000; Fri, 10 Jan 2020 11:03:30 +0800 From: "Gao, Zhichao" 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 Thread-Topic: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not Thread-Index: AdXHYf3Ye4pCg9vSQQi4Efzammpf9A== Date: Fri, 10 Jan 2020 03:03:30 +0000 Message-ID: <3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFA@SHSMSX101.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: zhichao.gao@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFASHSMSX101ccrcor_" --_000_3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFASHSMSX101ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI all, REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2298 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 reduc= e 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 c= lose source and open source. Can anyone give me some suggestions about this? Do we have a progress to re= tire some implementation in the edk2 repor? There is another question about MdePkg\Library\UefiDevicePathLib\UefiDevice= PathLibOptionalDevicePathProtocol.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 p= urpose? Local implementation, i.e. MdePkg\Library\UefiDevicePathLib\ UefiDevicePath= Lib.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 --_000_3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFASHSMSX101ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI all,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2298

In the MdePkg, there are two folder for the DevicePa= thLib:

1. &= nbsp; MdePkg\Library\UefiDevicePathLib

2. &= nbsp; MdePkg\Library\UefiDevicePathLibDevicePathProtocol<= o:p>

UefiDevicePathLibDevicePathProtocol is created to us= e the protocol to reduce the driver size which consume the DevicePathLib.

But it has duplicate code with #1. So I want to merg= e these two folder into one. But many platform implementations consume #2.<= o:p>

If we merge #2 into #1, there might be a lot of plat= form changes for both close source and open source.

Can anyone give me some suggestions about this? Do w= e have a progress to retire some implementation in the edk2 repor?

There is another question about MdePkg\Library\UefiD= evicePathLib\UefiDevicePathLibOptionalDevicePathProtocol.inf.

This one implements the interface to choose the prot= ocol first, then change to local implementation if no protocol is available= .

It requires a fix and it is already sent to the comm= unity. But what’s the purpose?

Local implementation, i.e. MdePkg\Library\UefiDevice= PathLib\ 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

--_000_3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFASHSMSX101ccrcor_--