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 9FE42208AE3E2 for ; Thu, 21 Feb 2019 00:55:55 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D677330821A0; Thu, 21 Feb 2019 08:55:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-111.rdu2.redhat.com [10.10.120.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id 205E95C665; Thu, 21 Feb 2019 08:55:52 +0000 (UTC) To: "Doran, Mark" , "Ni, Ray" , "Bi, Dandan" Cc: "edk2-devel@lists.01.org" , "Wu, Hao A" References: <20190215085141.64244-1-dandan.bi@intel.com> <20190215085141.64244-3-dandan.bi@intel.com> <3dbe48e2-3c1d-1cf8-3172-6a96e27ee454@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C026CBB@SHSMSX104.ccr.corp.intel.com> <0b3fbf1c-8acb-e1fd-d29e-98c36c9b81d1@redhat.com> From: Laszlo Ersek Message-ID: <08ffc80e-2e37-5317-182c-5da1391d0ff4@redhat.com> Date: Thu, 21 Feb 2019 09:55:52 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Thu, 21 Feb 2019 08:55:54 +0000 (UTC) Subject: Re: [patch 2/2] MdeModulePkg/BmBoot: Report status when fail to load/start boot option 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: Thu, 21 Feb 2019 08:55:55 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/20/19 18:19, Doran, Mark wrote: >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Wednesday, February 20, 2019 1:25 AM >> To: Ni, Ray ; Bi, Dandan >> Cc: edk2-devel@lists.01.org; Wu, Hao A ; Doran, Mark >> >> Subject: Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when >> fail to load/start boot option >> >> +Mark, for my comments on the process > > Thank you :) > >> On 02/20/19 03:21, Ni, Ray wrote: >>> Laszlo, >>> Thanks for catching this. >>> >>> GenPerformMemoryTest() in >>> MdeModulePkg\Universal\MemoryTest\GenericMemoryTestDxe\LightMemoryTest >>> .c uses the same technics as you suggested. >>> >>> I give up to propose another option: having pack(1) for the new status >> structure. >> >> I think that byte-packing EFI_RETURN_STATUS_EXTENDED_DATA in the PI-1.7 >> spec would have been viable, but we should have thought about that in >> advance. The PI and UEFI specs require natural alignment for structure >> members, unless stated otherwise. There *are* a number of examples of >> "stated otherwise" (the term that the specs use is frequently "byte-packed >> structure"). Again, we should have thought of that in advance, before PI- >> 1.7 was released, so now we can only fix the way the object is populated. > > Agreed. > >> More generally, I think this demonstrates a flaw in the standardization >> process. PIWG and USWG should only standardize existing practice; that is, >> features that have at least one functional implementation. (Not necessarily >> open source, but the interfaces should be battle-hardened >> *first*.) The restriction where we can't even propose patches for edk2 >> before the standards are updated is very counter-productive. There's >> practically zero chance for getting an actual implementation peer-reviewed >> and peer-tested before proposing the API for the standard. >> >> Personally I have suggested in the past to implement some new features as >> edk2 extensions first, and once they work, to upstream them to the >> standards. This idea is usually rejected by maintainers, because >> maintainers worry about becoming stuck with more and more edk2 extensions >> to core code (i.e., they worry about the feature proponents not making good >> on their promise to standardize). Unfortunately, the alternative (= the >> current practice) is that we standardize speculative interfaces, which then >> prove suboptimal once we implement them. > > So personally I'm a big believer in having working code for things we write down in the standards. When EFI was first drafted that's how we did it: what was then known as "the sample implementation" and the actual spec content were more or less developed in parallel and the spec wasn't done until the code was working satisfactorily. We got away from that largely because when the UEFI Forum was formed, there was nominal interest in promoting more than one implementation and keeping spec and code requirements separate was a part of that. > > Recent changes, particularly inside Intel, present an opportunity for us to revisit this issue. I'm advocating for the approach of spec-follows-code for new Contributions that Intel will make to the open source project going forward. I'll have more to say about this at upcoming industry events. > Sounds fantastic! Thank you! Laszlo