> The set of devices connected during BDS is platform policy. It is not > the "network stack" that calls Snp.Start(), but the platform BDS code > that calls gBS->ConnectController() on the device, possibly without a > good reason (e.g. without the device being present in a UEFI boot > option). The network stack only "reacts" to that connection request. Indeed, but even if a SNP handle is present as a boot option in a boot manager, surely the Snp.Start() should be deferred until the user actually chooses to boot from that handle.
A workaround that we have in the legacy implementation doesn't start the underlying hardware datapath until the platform tries to send the first packet (since PXE boot is always initiated by the client) but that is a horrible hack that should not be necessary. The distinction between Snp.Initialize() and Snp.Start() is there exactly for that reason, no? In other words, ConnectController() should not immediately result in Snp.Start() being called. Cheers, Tom _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
