From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 31A9D20955F39 for ; Fri, 2 Mar 2018 03:19:52 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D9F3A87ABA; Fri, 2 Mar 2018 11:26:00 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-104.rdu2.redhat.com [10.10.120.104]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9B5D946A9; Fri, 2 Mar 2018 11:25:59 +0000 (UTC) To: "Kinney, Michael D" , edk2-devel-01 Cc: "Justen, Jordan L" , Brijesh Singh , Ard Biesheuvel References: <20180302000408.14201-1-lersek@redhat.com> <20180302000408.14201-2-lersek@redhat.com> From: Laszlo Ersek Message-ID: <46394bdb-7608-397f-49fb-d66470da1f8d@redhat.com> Date: Fri, 2 Mar 2018 12:25:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 02 Mar 2018 11:26:00 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 02 Mar 2018 11:26:00 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 01/20] OvmfPkg/MemEncryptSevLib: rewrap to 79 characters width X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 11:19:52 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Mike, On 03/02/18 01:33, Kinney, Michael D wrote: > Laszlo, > > Sorting #includes looks strange to me. > > We usually include the top level environment include > first (e.g. ) and then the libs, protocols, > ppis, GUIDs grouped together. > > If it is a lib module, the produced libs are listed > first followed by the consumed libs. What you describe is the optimal structuring of the includes, and I do my best to comply with it when I post patches for core modules (MdePkg, MdeModulePkg, UefiCpuPkg, ...) However, under OvmfPkg and ArmVirtPkg, I have to disagree strongly. Many contributors lack either the knowledge or the discipline to follow the model that you describe. (Enforcing the model as a reviewer is also quite tedious.) Over time we end up with a mess of #include directives and LibraryClasses entries, where: - included library class headers, end entries under [LibraryClasses], do not match each other (or maybe they do, but it's hard to see because they are both sort of randomly ordered) - some headers are included "just to be safe" (they are not kept at a minimum) - especially after code removal and code movement, these parts are littered with dead entries. Keeping the lists sorted, while not entirely logical, greatly eases review and maintenance for me. (The sorting also happens to group Library/, Protocol/, Ppi/, Guid/, IndustryStandard/, Register/, etc includes "tightly", so at least those aren't intermixed.) Thanks Laszlo