From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web12.26745.1605011479782209130 for ; Tue, 10 Nov 2020 04:31:20 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZJA4/scp; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605011479; 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=ob/XLP3yMzTFZSWuo6pypTVkh6I//Lyotc9+21GXvXQ=; b=ZJA4/scp58AHEgU6ZFzK73PsEdecCGk3KafL2y/aC/jN7YwQRp4wcOHlf4dwjzZBvUz15w Edm5dwVPs/ZPJwNTLRVVkpSuWG1S/kzZN2DP3dKmSMy9L8PbnmfjHg5jjNR9022tV5IjQ8 KYEelxc2sZzTcK2QkRTNaD66fsEjsok= 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-8-OS-QI0RTMNyIVyF88yQfLg-1; Tue, 10 Nov 2020 07:31:17 -0500 X-MC-Unique: OS-QI0RTMNyIVyF88yQfLg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7DE9C1084D60; Tue, 10 Nov 2020 12:31:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-70.ams2.redhat.com [10.36.113.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2117E5B4C1; Tue, 10 Nov 2020 12:31:12 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native instruction support for X64 To: "Yao, Jiewen" , "Zurcher, Christopher J" Cc: "devel@edk2.groups.io" , gaoliming , "Wang, Jian J" , "Lu, XiaoyuX" , "Kinney, Michael D" , Ard Biesheuvel References: <20201103215834.7533-1-christopher.j.zurcher@intel.com> <1644D590FF4B7423.25549@groups.io> <7D73B5FD-CBCA-4E8C-B73B-930722C9FCF7@intel.com> From: "Laszlo Ersek" Message-ID: <903654d9-f903-734c-1d07-2f83a8c40099@redhat.com> Date: Tue, 10 Nov 2020 13:31:11 +0100 MIME-Version: 1.0 In-Reply-To: <7D73B5FD-CBCA-4E8C-B73B-930722C9FCF7@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/07/20 03:24, Yao, Jiewen wrote: > The reason we choose NASM is that we can use same assembly in windows build and Linux build. However if this NASM cannot be used in Linux, then the benefit does not exist any more. You can generate GAS to support GCC build, and check in .S file. I disagree with this idea. To me (as an exclusive GCC user), uniformity of assembly files is *much* more important than getting native instruction support in OpenSSL with all toolchains at the exact same time. If we enable native instruction support for (a) VS and CLANGPDB now, and (b) for GCC later, then that's two steps, with each step being in the forward direction. Performing just (a) for now creates no technical debt. A feature gap is not technical debt; you cannot mistake a missing feature for a working feature. If we re-add .S files now, for whatever purpose, that's a step *back*, however. It creates technical debt. A working feature on an invalid basis *can* be mistaken for a working feature, and we shouldn't do that (unless there are strong business needs for some participants, *AND* we have a *very specific* plan and timeline for backing out the hack). I really don't have any trust in technical debt being "paid" in edk2 anytime soon, though. Thanks Laszlo