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.web11.11510.1580405127916240102 for ; Thu, 30 Jan 2020 09:25:28 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hbfuHuJ5; 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=1580405127; 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=5p8lkSVhL50MT9qmlBouE62k7J6m4D7JZbgW85VrMZM=; b=hbfuHuJ5vflsqBfBera+rdeJNAImY49drGJSjqokRRpeqouwWGBj7XTC0Ccl2ELPlTpd4v TgP1715HRBx5UGYxouTZ4vJreWJysVwAw6l27V5Q7rSWkOoEdBV4MXJKwykZsZdzddFi1e TypIkzNMxzwRwXLbWIz1SzQVLEtT2Jo= 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-431-L1M4Z3CQPcyxEO4sN3pA3g-1; Thu, 30 Jan 2020 12:25:22 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CE209477; Thu, 30 Jan 2020 17:25:20 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-35.ams2.redhat.com [10.36.117.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id CF62360BE1; Thu, 30 Jan 2020 17:25:18 +0000 (UTC) Subject: Re: [edk2-devel] [Patch 3/5] CryptoPkg/Driver: Add Crypto PEIM, DXE, and SMM modules To: "Kinney, Michael D" , "devel@edk2.groups.io" , Sean Brogan , "'Bret.Barkelew@microsoft.com'" , Matthew Carlson Cc: "Wang, Jian J" , "Lu, XiaoyuX" , Ard Biesheuvel References: <20200130070037.8516-1-michael.d.kinney@intel.com> <20200130070037.8516-4-michael.d.kinney@intel.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 30 Jan 2020 18:25:17 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: L1M4Z3CQPcyxEO4sN3pA3g-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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