On 15/10/15 23:33, Andrew Fish wrote:
The EFI Driver Model, lets you connect and disconnect, drivers as needed. The
EFI networking stack supports the EFI Manged Network Protocol to help manage
the network stack configuration. This is what was intended for normal operation.
I’m just guessing but the iPXE developers have to deal with multiple
environments (Legacy BIOS, EFI, …) and probably picked a path that allowed all
these “worlds” to have a similar code flow. So the EFI OpenProtocol EXCLUSIVE
probably mapped into the other flows where iPXE just takes over. If you are
maintaining a complex networking stack (iPXE) trying to make it as common as
possible in all its various ports does not seem like an unreasonable goal, but
you might not end up with the ideal implementation for each environment.
That's part of it. Other important reasons are:
1. We want to minimise our exposure to buggy firmware implementations,
by using as few of the firmware-provided facilities as possible. If we
have a native iPXE driver for the NIC hardware then we will explicitly
rip out any attached MNP, SNP and NII drivers, plug ourselves in (via
the UEFI driver model) as the driver for the underlying PCI device, and
control the hardware directly. If we don't have a native driver (e.g.
in snponly.efi) then we'll fall back to ripping out just MNP and SNP and
taking exclusive ownership of the NII device.
2. We actually care about performance. A "good" MNP-attached driver
might be able to achieve 10Mbps on a 1000Mbps NIC. We expect to achieve
the full 1000Mbps in iPXE.
However, the fact that iPXE takes exclusive ownership of the underlying
device should not matter, because we always expose a new device handle
onto which we install SNP, NII, PxeBc, LoadFile, etc. Whatever we load
will be given this new handle as the DeviceHandle.
Michael
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
