Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native instruction support for X64

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

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 <lersek@redhat.com>
>> Sent: Tuesday, November 10, 2020 8:31 PM
>> To: Yao, Jiewen <jiewen.yao@intel.com>; Zurcher, Christopher J
>> <christopher.j.zurcher@intel.com>
>> Cc: devel@edk2.groups.io; gaoliming <gaoliming@byosoft.com.cn>; Wang,
>> Jian J <jian.j.wang@intel.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>; Kinney,
>> Michael D <michael.d.kinney@intel.com>; Ard Biesheuvel
>> <ard.biesheuvel@arm.com>
>> 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
>