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.web12.18962.1584117414780184285 for ; Fri, 13 Mar 2020 09:36:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ghrfqtzf; 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=1584117413; 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=rYBK/hP0rWQG5gdwLAy9IFrRePnSeGIxxIwzHNZVfPY=; b=ghrfqtzf5BnHiVWgF+0eqrliBfEXDKGqGT6rmW4iYIJ5y1EBtSU3YY61S15acu8Eitv3r/ 7QwIv8LB2D3HwBYATRhJaY0Q1mOVmHzo8qREzRdr7sn1HHUQ6+TIeeu9RaNW6SlGVNteDh NH8X8qFTDel3hN67rziK3RMuP9MI2gw= 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-303-3mTUoGWkM1meA6fNy5HLnA-1; Fri, 13 Mar 2020 12:36:51 -0400 X-MC-Unique: 3mTUoGWkM1meA6fNy5HLnA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E2545184D262; Fri, 13 Mar 2020 16:36:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-172.ams2.redhat.com [10.36.117.172]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0E0B560BEE; Fri, 13 Mar 2020 16:36:38 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment To: Leif Lindholm , devel@edk2.groups.io Cc: "Chang, Abner (HPS SW/FW Technologist)" , "Schaefer, Daniel (DualStudy)" , "Chen, Gilbert" , "afish@apple.com" , "michael.d.kinney@intel.com" , "pete@akeo.ie" , Ard Biesheuvel References: <20200302103238.25726-1-daniel.schaefer@hpe.com> <20200302103238.25726-4-daniel.schaefer@hpe.com> <20200312105528.GC23627@bivouac.eciton.net> <539c8673-786c-9c58-98cc-ab470b345740@hpe.com> <20200312140304.GF23627@bivouac.eciton.net> <20200312144452.GI23627@bivouac.eciton.net> <20200312211953.GL23627@bivouac.eciton.net> From: "Laszlo Ersek" Message-ID: <7e41a4f8-dfb5-17da-db7a-b66516e9f346@redhat.com> Date: Fri, 13 Mar 2020 17:36:36 +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: <20200312211953.GL23627@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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 03/12/20 22:19, Leif Lindholm wrote: > On Thu, Mar 12, 2020 at 20:42:52 +0100, Laszlo Ersek wrote: >> On 03/12/20 15:44, Leif Lindholm wrote: >>> And what would you propose we do the next time the RISC-V toolchain >>> generates a memcpy call based on some other completely valid change to >>> core code? >> >> We could choose to enable the intrinsics library for RISC-V at that point. > > We could. And have no time left for resolving any issues that may be > triggered by that without slipping the next stable tag. I would prefer > de-risking it. OK. >> IIUC, the CreateDeviceManagerForm() code in question did break an edk2 >> rule ("don't use structure assignment") *prior* to commit 64a228f5f893. >> The rule violation was in commit 32465d9ae7ee; RISC-V only exposed it. >> This doesn't seem uncharted territory. > > I don't understand, I've already said I'm not pushing to revert that > patch, I have suggested that we don't put RISC-V on less stable ground > than ARM/AARCH64. Apologies, I was unclear. By "not uncharted territory", I meant that it's not uncommon for new code (regardless of architecture) to expose dormant issues in old code. In particular the "no struct assignment" rule is not being broken for the first time. Anyway, I'm not opposing your suggestion. > But continuing on the unrelated topic: > If the rule is "no structure assignments", then fine, that's part of > the C dialect you need to learn in order to contribute to TianoCore. > I can separately start arguing for changing that rule. *That* would be awesome, if it can be pulled off universally (arch-independently), and hopefully without performance loss. (I do agree it's unlikely that we'll have tight loops with CopyGuid() etc.) > However, I can't easily find that in the coding style - could you give > me a pointer? I'm not even going to look now: I believe I tried that earlier, and it's not in the edk2 CCS (AFAIR). It's by word of mouth. Laszlo