On 02/20/19 18:19, Doran, Mark wrote: >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Wednesday, February 20, 2019 1:25 AM >> To: Ni, Ray <ray...@intel.com>; Bi, Dandan <dandan...@intel.com> >> Cc: edk2-devel@lists.01.org; Wu, Hao A <hao.a...@intel.com>; Doran, Mark >> <mark.do...@intel.com> >> 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
