Re: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecate function

["Ni, Ray" <ray.ni@intel.com>]

Jiewen,
comments below.

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
> Sent: Friday, March 27, 2020 2:16 PM
> To: Fu, Siyuan <siyuan.fu@intel.com>; devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@intel.com>
> Cc: Wang, Jian J <jian.j.wang@intel.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>; Maciej Rabeda
> <maciej.rabeda@linux.intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>
> Subject: Re: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecate function
> 
> Library is static interface. Protocol is dynamic interface. That is key difference.
> 
> My understanding for a *private protocol* is that: one module in the package to produce. The other module in the same
> packet to consume. Both are at runtime. That brings zero impact to other module.

If a module produces public Protocol_A and internally consumes private Protocol_B, do you think that Protocol_B is private? I still think it's private. The module is responsible to make sure Protocol_A behavior is not impacted by a internal change of Protocol_B.

I didn't investigate the specific issue in detail.
But in general, any change needs to consider the backward compatibility.
An interface is ok to change when all modules that consume this interface are updated, no matter it's private or public.

In this case, I think the library that calls the private protocol needs to change.

Through this way, each layer owns it's promise to its consumers.

Thanks,
Ray