From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web10.7931.1578649190002166934 for ; Fri, 10 Jan 2020 01:39:50 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.43, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2020 01:39:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,415,1571727600"; d="scan'208,217";a="254931190" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 10 Jan 2020 01:39:49 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 10 Jan 2020 01:39:49 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 10 Jan 2020 01:39:48 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.197]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.89]) with mapi id 14.03.0439.000; Fri, 10 Jan 2020 17:39:47 +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: AdXHYf3Ye4pCg9vSQQi4Efzammpf9AAJePxgAABZXEAABALn8A== Date: Fri, 10 Jan 2020 09:39:46 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C3E846D@SHSMSX104.ccr.corp.intel.com> References: <3CE959C139B4C44DBEA1810E3AA6F9000B8C0AFA@SHSMSX101.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C3E8084@SHSMSX104.ccr.corp.intel.com> <3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <3CE959C139B4C44DBEA1810E3AA6F9000B8C1D08@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_734D49CCEBEEF84792F5B80ED585239D5C3E846DSHSMSX104ccrcor_" --_000_734D49CCEBEEF84792F5B80ED585239D5C3E846DSHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, the impact is every platform DSC needs to be updated to reference the c= orrect path of the UefiDevicePath lib after your merge. 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 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 >; dev= el@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 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_734D49CCEBEEF84792F5B80ED585239D5C3E846DSHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, the impact is every platform DSC needs to be upd= ated to reference the correct path of the UefiDevicePath lib after your mer= ge.

 

Let’s wait for at least 2 weeks for feedbacks.=

 

Thanks,

Ray

 

From: Gao, Zhichao <zhichao.gao@intel.com&= gt;
Sent: Friday, January 10, 2020 3:47 PM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; 'rfc@edk= 2.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

 

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 <zhicha= o.gao@intel.com>; devel@edk2.groups.io; 'rfc@edk2= .groups.io' <rfc@edk2.groups.io>
Cc: Gao, Liming <liming.g= ao@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_734D49CCEBEEF84792F5B80ED585239D5C3E846DSHSMSX104ccrcor_--