Oops, I got carried away a little bit, and forgot about a crucial detail: On 07/22/15 00:58, Laszlo Ersek wrote:
[snip] > (1) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3799 > Date: 2015-Jan-27 > feedback: none > > (2) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3955 > Date: 2015-Feb-10 > feedback: zero > > (3) [PATCH] [efi] make load file protocol optional > http://thread.gmane.org/gmane.network.ipxe.devel/3815 > Date: 2015-Feb-11 > feedback: the patch destroys the user's ability to use > most features of iPXE > our point: we don't care about most features of iPXE, we just need > it for EFI drivers (Simple Network Protocol instances) > result: nothing Mark this ^^^ > > (4) [RESENT PATCH 0/2] efi boot fixes. > http://thread.gmane.org/gmane.network.ipxe.devel/3854 > Date: 2015-Mar-10 > feedback: zilch > > (5) [RESEND PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/3934 > Date: 2015-Apr-14 > feedback: nada > > (6) [PATCH] efi_snp: improve compliance with the > EFI_SIMPLE_NETWORK_PROTOCOL spec > http://thread.gmane.org/gmane.network.ipxe.devel/4096 > Date: 2015-Jun-10 > feedback: null [snip] > On the technical level, let me summarize: we needed three patches in > total to get UEFI boot working: > > #1 efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec > #2 [efi] make load file protocol optional > #3 [efi] Ensure drivers are disconnected when ExitBootServices() is > called > > Wrt. #1, the maintainer expressed agreement on IRC, but never replied to > patch emails. > > Wrt. #2, the maintainer expressed strong disagreement (due to "user > interface" concerns) on both IRC and later on the mailing list. > Therefore the idea of upstreaming this patch is dead in the water. The > maintainer would accept an alternative that would take a huge > development effort, and would be useless for virtualization purposes > (ie. PXE-booting with OVMF in QEMU). So, the important detail that I forgot is that Gerd's patch, listed as #2 here, and as (3) above in the list of earlier submissions, actually does not change the behavior of ipxe *at all*. It just introduces a config option, a knob if you like, that allows downstreams to rebuild ipxe *that specific way* easily. Therefore, absolutely no user interface concerns are valid in this case -- those concerns may have been correct for my very first patch, but Gerd reworked the patch to depend on a new config option (with unchanged default behavior), and the maintainer refused to take even that. (Despite the fact that upstream iPXE users would see no change in behavior.) Laszlo > > Wrt. #3, the maintainer decided to look at the patch, rewrite it, and > commit it. For some unfathomable reason. Maybe because he was Cc'd > directly on the patch email. I don't know. (The ipxe-devel list has > absolutely minimal traffic, why wouldn't he read it without explicit Cc?!) > > This PULL is about getting #3 via rebase, and #1 and #2 as downstream > patches. > > Thanks > Laszlo >
