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.web10.1466.1601316974824398170 for ; Mon, 28 Sep 2020 11:16:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I9aXYXI9; 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=1601316974; 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=a7GTWaDBukI61QwAO3szDEJLj1t90Dvm0buG2miXNj4=; b=I9aXYXI99kUBADM2GRZbLViDWPfNKrqoCDqJoWblFMd8U3E8Rj0jD96qPzW3K4EGYsWjQa 2bPT4EthqZ+jVr7Dnbp3FKL0CHzEANhWi9/J2oipr49sG19Psko1vnsJCxwc9bEl2XWMYI WIoz3wQkZE2+zbFoB/8+wxlfJuWaOk8= 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-272-Eodo2CJYNhOiOO9dtG761g-1; Mon, 28 Sep 2020 14:16:08 -0400 X-MC-Unique: Eodo2CJYNhOiOO9dtG761g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DC7D980733A; Mon, 28 Sep 2020 18:16:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-138.ams2.redhat.com [10.36.113.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id D48B65D9CC; Mon, 28 Sep 2020 18:16:05 +0000 (UTC) Subject: Re: [EXTERNAL] [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures. To: devel@edk2.groups.io, afish@apple.com, Bret Barkelew Cc: Ken Taylor References: <29096719f8d541c3aa25f9738a61b1d3@SCL-EXCHMB-13.phoenix.com> <4929ABCC-75D2-42B3-938D-EE9C78B1FFDD@apple.com> From: "Laszlo Ersek" Message-ID: <69add2ee-9903-9fc5-4631-b50061171ba2@redhat.com> Date: Mon, 28 Sep 2020 20:16:04 +0200 MIME-Version: 1.0 In-Reply-To: <4929ABCC-75D2-42B3-938D-EE9C78B1FFDD@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: 8bit On 09/26/20 04:52, Andrew Fish via groups.io wrote: > Bret, > > Details aside this ECC issue got me thinking it might be useful to some how tag code that follows different, subsetted, or alternate rules, or uses different build environments. I was kind of thinking of doing something like how we tag the licenses in the header comments [1]. I would say nothing means edk2 rules. I can see vendors maybe having different internal rules, or us wanting to distinguish test code from production code. The general idea if we start this tools can be smarter and that seems like a good thing. > > This is just a wild idea, so I’d like to see what other people think? Concerning header files that help edk2 interface with other systems -- although it's more work, I prefer re-coding those header files manually (even better: coding them afresh from published specs!), over importing (otherwise license-compatible) headers from other projects. In my experience, this sustains a very "native" look & feel to edk2, plus it's an awesome incentive for programmers to add the structs and macros that are *really* needed for the upcoming drivers / applications. Thanks! Laszlo