From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx.groups.io with SMTP id smtpd.web09.7359.1578642432329482930 for ; Thu, 09 Jan 2020 23:47:12 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: zhichao.gao@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2020 23:47:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,415,1571727600"; d="scan'208,217";a="422030908" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga005.fm.intel.com with ESMTP; 09 Jan 2020 23:47:11 -0800 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 23:47:11 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 23:47:11 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.30]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.132]) with mapi id 14.03.0439.000; Fri, 10 Jan 2020 15:47:09 +0800 From: "Gao, Zhichao" 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 Thread-Topic: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not Thread-Index: AdXHYf3Ye4pCg9vSQQi4Efzammpf9AAJePxgAABZXEA= Date: Fri, 10 Jan 2020 07:47:09 +0000 Message-ID: <3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08@SHSMSX101.ccr.corp.intel.com> References: <3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFA@SHSMSX101.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C3E8084@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C3E8084@SHSMSX104.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_3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08SHSMSX101ccrcor_" --_000_3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08SHSMSX101ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, I prefer to merge these two lib instance into one folder and remove the dup= licated 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 chang= ing 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.g= roups.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 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_3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08SHSMSX101ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,=

I prefer to merge thes= e two lib instance into one folder and remove the duplicated code.

I can change all the r= equired change in open source repo. But not sure how many close source plat= forms would be affected.

This action should mak= e all the close platform owners aware of it and changing their platform cod= e to consume the new lib instance.

 

#2: OK. That makes sen= se 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 <zhichao.gao@intel.com>; devel@edk2.groups.io= ; 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Gao, Liming <liming.gao@intel.com>; Kinney, Michael D <= michael.d.kinney@intel.com>; 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/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>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io= ; 'rfc@edk2.groups.io' <rfc@edk2.g= roups.io>
Cc: Gao, Liming <liming.g= ao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; vit9696@protonmail.com; Ni, R= ay <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\Ue= fiDevicePathLib
  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_3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08SHSMSX101ccrcor_--