From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.11632.1605121661815022727 for ; Wed, 11 Nov 2020 11:07:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OKAD+5wu; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605121661; 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=r6sTLb3bL0tN1UF7Ubm7oparYvHNIpoFXaaF2k6rwbg=; b=OKAD+5wudgMyfFp9N3xu1Icu19Qtlf4rj4f/BccI5k9Ag4VYPGY7mW0uv69gJuR9amNohU SiIiJIXr2nf07etw51YlTJveutKVlDt8jq4YnefPr6hdlwBVdzInw56R5IzU+QoGRfZ7B9 AzsYYHY7VcX8pMQ/3HGQTdEmYIqbj90= 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-397-tEw3lEg8MaijgkwoIwPMaA-1; Wed, 11 Nov 2020 14:07:38 -0500 X-MC-Unique: tEw3lEg8MaijgkwoIwPMaA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 272C11074665; Wed, 11 Nov 2020 19:07:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-85.ams2.redhat.com [10.36.113.85]) by smtp.corp.redhat.com (Postfix) with ESMTP id C47931002C28; Wed, 11 Nov 2020 19:07:34 +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> <903654d9-f903-734c-1d07-2f83a8c40099@redhat.com> From: "Laszlo Ersek" Message-ID: <87419aa9-c5c5-be7f-cf7b-f5f555b76fa5@redhat.com> Date: Wed, 11 Nov 2020 20:07:33 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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/10/20 18:07, Yao, Jiewen wrote: > Laszlo. > If you disagree, what is your proposal? My proposal would have been to simply not enable native insn support via GCC at this time. But, as Liming points out, I was simply wrong; so GAS generation should be tolerable in this particular case. Because, no manual maintenance is needed; both NASM and GAS files can be regenerated, if necessary, with the same effort. (The problem with the historical .S files was that every manual assembly language development had to be done in multiple dialects.) Thanks, Laszlo > > >> -----Original Message----- >> From: Laszlo Ersek >> Sent: Tuesday, November 10, 2020 8:31 PM >> To: Yao, Jiewen ; Zurcher, Christopher J >> >> Cc: devel@edk2.groups.io; gaoliming ; Wang, >> Jian J ; Lu, XiaoyuX ; Kinney, >> Michael D ; Ard Biesheuvel >> >> Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native >> instruction support for X64 >> >> 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 >