From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web10.7151.1578641792324972776 for ; Thu, 09 Jan 2020 23:36:32 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2020 23:36:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,415,1571727600"; d="scan'208,217";a="218589710" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga008.fm.intel.com with ESMTP; 09 Jan 2020 23:36:31 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 23:36:31 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.197]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.30]) with mapi id 14.03.0439.000; Fri, 10 Jan 2020 15:36:29 +0800 From: "Ni, Ray" 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 Thread-Topic: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not Thread-Index: AdXHYf3Ye4pCg9vSQQi4Efzammpf9AAJePxg Date: Fri, 10 Jan 2020 07:36:29 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C3E8084@SHSMSX104.ccr.corp.intel.com> References: <3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFA@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFA@SHSMSX101.ccr.corp.intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_734D49CCEBEEF84792F5B80ED585239D5C3E8084SHSMSX104ccrcor_" --_000_734D49CCEBEEF84792F5B80ED585239D5C3E8084SHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zhichao, What's your recommendation regarding this? Back to your 2nd question, drivers/applications consuming UefiDevicePathLib= OptionalDevicePathProtocol can firstly use the firmware built-in from-text and to-text conversion, the= n 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 rec= ognize 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=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_734D49CCEBEEF84792F5B80ED585239D5C3E8084SHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Zhichao,

What’s your recommendation regarding this?

 

Back to your 2nd question, drivers/applic= ations consuming UefiDevicePathLibOptionalDevicePathProtocol
can firstly use the firmware built-in from-text and to-text conversion, the= n 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 i= n year 2015, it can recognize the new device path node
introduced after 2015 in a new system.

 

Thanks,

Ray

 

From: Gao, Zhichao <zhichao.gao@intel.com&= gt;
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io; 'rfc@edk2.groups.io' <rfc@edk2.groups.i= o>
Cc: Gao, Liming <liming.gao@intel.com>; Kinney, Michael D <= michael.d.kinney@intel.com>; vit9696@protonmail.com; Ni, Ray <ray.ni@= intel.com>
Subject: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not=

 

HI all,

 

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

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

  1. MdePkg\Library\UefiDevicePathLib
  2. MdePkg\Library\= UefiDevicePathLibDevicePathProtocol

 

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_734D49CCEBEEF84792F5B80ED585239D5C3E8084SHSMSX104ccrcor_--