Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support

[Laszlo Ersek]

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
>