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