From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 5853E208D615F for ; Mon, 25 Feb 2019 02:54:38 -0800 (PST) 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 mx1.redhat.com (Postfix) with ESMTPS id D15F73DE07; Mon, 25 Feb 2019 10:54:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-217.rdu2.redhat.com [10.10.120.217]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8FADF60863; Mon, 25 Feb 2019 10:54:36 +0000 (UTC) To: "Ni, Ray" , "edk2-devel@lists.01.org" Cc: "Wu, Hao A" , "Bi, Dandan" , "Zeng, Star" References: <20190221104112.14995-1-lersek@redhat.com> <20190221104112.14995-2-lersek@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C02CEB3@SHSMSX104.ccr.corp.intel.com> <4e739d1b-44a5-f2a2-3f0f-84f3c700e2b2@redhat.com> <0a59efb2-45cb-51b4-60d6-9cf3a125c9cb@Intel.com> From: Laszlo Ersek Message-ID: Date: Mon, 25 Feb 2019 11:54:35 +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: <0a59efb2-45cb-51b4-60d6-9cf3a125c9cb@Intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 25 Feb 2019 10:54:37 +0000 (UTC) Subject: Re: [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 10:54:38 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/25/19 09:27, Ni, Ray wrote: > On 2/23/2019 1:16 AM, Laszlo Ersek wrote: >> Yes, I was fully aware of that. >> >> However: >> >> The issue is that, in the BmReportLoadFailure() function, we do some >> work*before*  we call REPORT_STATUS_CODE_EX(). We have an ASSERT(), a >> ZeroMem(), and a field assignment. >> >> If status code reporting is disabled for EFI_ERROR_CODE in the platform, >> then said work will be wasted. We can optimize this by checking for >> ReportErrorCodeEnabled() up-front, because we know for sure that later >> on we will report the status code with EFI_ERROR_CODE type. >> >> In other words, this approach is similar to DEBUG_CODE(). In some cases, >> logging a piece of information with DEBUG() takes non-trivial >> computation. And it would be a waste, for example in RELEASE builds, to >> perform the computation, and then throw away only the result (the log >> message). Therefore the DEBUG_CODE macro is used, and the whole work is >> eliminated in RELEASE builds. >> >> The idea is the same here. If the compiler can statically deduce that >> ReportErrorCodeEnabled() will always return FALSE -- for example because >> the ReportStatusCodeLib instance in question looks at >> "PcdReportStatusCodePropertyMask", and the PCD is Fixed-at-Build, and >> the corresponding bit is clear --, then the compiler can eliminate the >> entire BmReportLoadFailure() function. This is good for both flash usage >> and for performance. >> >> I'm fine either way, but first, please confirm again that you really >> want me to remove the ReportErrorCodeEnabled() check, before pushing. >> >> Thanks! >> Laszlo > > Thanks for the explanation. I am fine with both. > Reviewed-by: Ray Ni > Thank you, Ray. I opted for pushing v3 as-is. Laszlo