[RFC] BZ 2298 MdePkg/DevicePathLib merger or not

[RFC] BZ 2298 MdePkg/DevicePathLib merger or not

[Gao, Zhichao]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 7096 bytes --]

Re: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

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 <zhichao.gao@intel.com>
Sent: Friday, January 10, 2020 11:04 AM
To: 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; 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=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


[-- Attachment #2: Type: text/html, Size: 7557 bytes --]

Re: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

[Gao, Zhichao]

[-- Attachment #1: Type: text/plain, Size: 3113 bytes --]

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 <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/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 <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; vit9696@protonmail.com<mailto:vit9696@protonmail.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
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


[-- Attachment #2: Type: text/html, Size: 9716 bytes --]

Re: [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]

So, the impact is every platform DSC needs to be updated to reference the correct path of the UefiDevicePath lib after your merge.

Let's wait for at least 2 weeks for feedbacks.

Thanks,
Ray

From: Gao, Zhichao <zhichao.gao@intel.com>
Sent: Friday, January 10, 2020 3:47 PM
To: Ni, Ray <ray.ni@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

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 <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; vit9696@protonmail.com<mailto: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 <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>
Sent: Friday, January 10, 2020 11:04 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; vit9696@protonmail.com<mailto:vit9696@protonmail.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
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


[-- Attachment #2: Type: text/html, Size: 11406 bytes --]

Re: [edk2-devel] [RFC] BZ 2298 MdePkg/DevicePathLib merger or not

[Laszlo Ersek]

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 <zhichao.gao@intel.com>
> Sent: Friday, January 10, 2020 3:47 PM
> To: Ni, Ray <ray.ni@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
> 
> 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 <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; vit9696@protonmail.com<mailto: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 <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>
> Sent: Friday, January 10, 2020 11:04 AM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 'rfc@edk2.groups.io' <rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; vit9696@protonmail.com<mailto:vit9696@protonmail.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> 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
> 
> 
> 
> 
>