Re: [edk2-devel] [Patch 3/5] CryptoPkg/Driver: Add Crypto PEIM, DXE, and SMM modules

["Laszlo Ersek" <lersek@redhat.com>]

On 01/30/20 18:10, Kinney, Michael D wrote:

> 3) EDK II community defines a small number of profiles
>    for the PEI, DXE, SMM versions of these modules and
>    publishes released binaries for each profile.  Platforms
>    integrate the published binary modules.  This may 
>    provide more services than are required for some platforms
>    but has the advantage of using a released binary from
>    the EDK II project and reducing build times.  Once again,
>    some guidance and/or tools may be required to help the
>    EDK II community determine the right number of profiles
>    and the services enabled in each profile.

This sounds super interesting; I didn't think of it!

The great property of profiles seems to be that they strike a middle
ground between space savings and call safety. Namely:

- let's say we define 4 profiles,

- each profile comes with its own *wrapper* crypto API lib instance,

- in each such lib instance, the wrapper functions for those PPI /
protocol member APIs that are disabled in the PCD are *also not
implemented*, thereby causing linkage failures if a module tries to use them

- given that there are only 4 profiles, a platform can exhaustively test
building against each, and find the smallest one that works -- and
repeatably so: it's never a "bad time" to attempt building against a
smaller profile!

- in the smallest applicable profile, some functions might be included
uselessly in the PPI / protocol providers -- but not too many. That's
why we didn't pick a larger profile. And whatever is included, will be
shared between consumers.

This should work even without distributing the PPI / protocol providers
in binary form.

I think this could be a valid use case for some library instances in
edk2 *not* to implement all functions from the library class header.

Thanks!
Laszlo