From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) by mx.groups.io with SMTP id smtpd.web10.7747.1584072525228312080 for ; Thu, 12 Mar 2020 21:08:45 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0341df3555=abner.chang@hpe.com) Received: from pps.filterd (m0134423.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02D45mcu023164; Fri, 13 Mar 2020 04:08:42 GMT Received: from g2t2352.austin.hpe.com (g2t2352.austin.hpe.com [15.233.44.25]) by mx0b-002e3701.pphosted.com with ESMTP id 2yr0jnruhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 04:08:42 +0000 Received: from G1W8107.americas.hpqcorp.net (g1w8107.austin.hp.com [16.193.72.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2352.austin.hpe.com (Postfix) with ESMTPS id EEFDAA7; Fri, 13 Mar 2020 04:08:40 +0000 (UTC) Received: from G4W9120.americas.hpqcorp.net (2002:10d2:150f::10d2:150f) by G1W8107.americas.hpqcorp.net (2002:10c1:483b::10c1:483b) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 13 Mar 2020 04:08:15 +0000 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (15.241.52.13) by G4W9120.americas.hpqcorp.net (16.210.21.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 13 Mar 2020 04:08:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GlGGOzqpf5HCmi0ERhs5E6EfXSG5NaAbPCmTdKVjGvXcmdg1bhXhynMscPErPis7sZ5eKK/cU1HhxBYvmsKDrknYMLuiZWv0DhXsrkDHK8vbVW65JNW3ayCvU3eDdUNEKog66LV4qdcPKuRWHncKxggioIV/Lo7H6X8mGZUEn6HqybUwuRxF09DsNX3TFXebQT84PClXGh7PRtheK9KAXQ1BnIPr1PEEAaZn8rU4hgklK6ZmmkS0rY3XLYLMHRs8J7BiZEHBNbLeWvX5WhplTfyGfG6/CCZhtMbdFrXtJ5lNgIRANkiGw5zjUd6IqXoqXo5x0C7pisNmOEAUm9Nr6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yX52+zgWOuqQALq8ee/3bop3S63p3xNqr7uCpIkBsfA=; b=bM5exyke3kPG6i2rcXEQAMpDVNg21FHeKlnVD1eqU5VEq8H92rQLLnuM2vqrC7Hx+96env4VXpVsKFDhRxz0J7Li/zIQ2ph7YdoJAjI6cYFwmK6gQ0mRuNhkYiGoU1ZDo7nQSloh/RKB8CZYzSceLHkRcYs9SrcLgLQbpkz1Ku1xH7kwEtRHYYQU5x76g5rgVYVwpl2WHC0lDL4j7uz/xMxHjZphgGVjjL00wXHlNBhzaak15MEXdz9+q87KZCPPSS+pj6PCMfk3IwISobpwBBS67kf8XtcFFvwuMh0Y86+12MF7zCYKN2dM9TanlUUSeF6JN+BRuzXQ9ILCWLQKFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:770a::14) by TU4PR8401MB0493.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:770a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Fri, 13 Mar 2020 04:08:13 +0000 Received: from TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM ([fe80::b0b5:c067:8f22:a402]) by TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM ([fe80::b0b5:c067:8f22:a402%6]) with mapi id 15.20.2793.018; Fri, 13 Mar 2020 04:08:13 +0000 From: "Abner Chang" To: Leif Lindholm , "devel@edk2.groups.io" , "lersek@redhat.com" CC: "Schaefer, Daniel (DualStudy)" , "Chen, Gilbert" , "afish@apple.com" , "michael.d.kinney@intel.com" , "pete@akeo.ie" , Ard Biesheuvel Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment Thread-Topic: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment Thread-Index: AQHV8H3y8ONhWG4a20uPbA3rSjizB6hE2H8AgAAppACAAArJAIAAAoZwgAAJJQCAAFNDAIAAGxuAgABut4A= Date: Fri, 13 Mar 2020 04:08:12 +0000 Message-ID: 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> In-Reply-To: <20200312211953.GL23627@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.242.247.131] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 076e6d46-fc08-49ee-ecb0-08d7c7042626 x-ms-traffictypediagnostic: TU4PR8401MB0493: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 034119E4F6 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(136003)(39860400002)(396003)(346002)(366004)(376002)(199004)(110136005)(186003)(66476007)(76116006)(316002)(66946007)(54906003)(2906002)(26005)(66556008)(64756008)(66446008)(8936002)(6506007)(53546011)(52536014)(9686003)(5660300002)(478600001)(71200400001)(55016002)(8676002)(81156014)(81166006)(7696005)(33656002)(4326008)(86362001);DIR:OUT;SFP:1102;SCL:1;SRVR:TU4PR8401MB0493;H:TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8iIe+fHm/ky5WgbxRCyCivkXb2KQg3NQQCSOVLfz42tsUCfIWsajZie48Fs2izf9EFf1u2ySbfe3AsXznlL1Dp3hPcVaHCPeu+2V6JxZDdjMOPx25zVAQni0KKRzIW573Waj8nINBWAuSk4849nP7Wg6ceyH51P2xcQDA9BY5iSuJh2K+KlYZ0DJpak2S9tFQNkeN15n/BALfUJAOKx9mwinquPgq7vgC223K4yZXxonod2V0JtTdhCgP1N1hhrCe24UfsWRjkDRNM5s8ZeHvMDOufdjIYWu3jG1rMOcxUhQOcMpQAl24Sr4qzNUmZtPFzu67GY3WtM/YXBfTX+K7Rv0Y/qRXsVabwRiUUoTmQ+TMU0CaNQ/O2RFUyrZ3eDgAbysVbBA+SiFUqlUDxWHjTwuM8GJJzY6NNgIG5lynu8LN0+jzeWLKya3QH+FssdS x-ms-exchange-antispam-messagedata: kK8lWF75Be2iJ22OUDcmICDsTxyJ+n/ocor9rgWMcbTN7ozjBin8xBjGDVQNp7Wv/vTUSI1uhaxhwR9bKXpb+XzJ29vlnGwQxbpGq+chXp7KfT5FDILy1f/8rSoPmPA7lUZYad+ArVcKsB8yI3T+Tg== X-MS-Exchange-CrossTenant-Network-Message-Id: 076e6d46-fc08-49ee-ecb0-08d7c7042626 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 04:08:12.9176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: humuIHPPbj/SeXxmnq092KgfNGRBeqRWr1W8Qbc5SQwKHc5fEfy26toxUq9cQ+m3pZlI++7MCmLFXB5y0YjDYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR8401MB0493 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-03-12_19:2020-03-11,2020-03-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 clxscore=1015 suspectscore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 impostorscore=0 spamscore=0 bulkscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003130021 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Leif Lindholm [mailto:leif@nuviainc.com] > Sent: Friday, March 13, 2020 5:20 AM > To: devel@edk2.groups.io; lersek@redhat.com > 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 > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem > instead of GUID assignment The current NULL instance of CompilerIntrinsicsLib is applied on every modu= les, this means it's not flexible for overwriting memcpy (for example) with= the faster algorithm (such as SSEx instructions) for the specific module i= n the same DSC, right? That says we can't assign a special version of memcp= y to just one particular module.=20 >=20 > 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 poi= nt. and I would like to see the flexibility of overwriting memory library funct= ions for particular modules. There is no special algorithm of memory manipu= lation so far in RISC-V spec, however, the working group of Vector extensio= n does propose the new instruction sets. >=20 > 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. >=20 > > 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. >=20 > I don't understand, I've already said I'm not pushing to revert that patc= h, I > have suggested that we don't put RISC-V on less stable ground than > ARM/AARCH64. >=20 > 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. > However, I can't easily find that in the coding style - could you give me= a > pointer? >=20 > / > Leif