On 01/23/19 17:27, Tomas Pilar (tpilar) wrote: > >> 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. Yes, I agree. As far as I remember, UefiBootManagerLib is compatible with that idea (it makes sure the device path is connected before the boot is attempted). So again, the deferral you suggest applies to platform BDS. > 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? That's a good question; if someone finds the answer, please let me too know! :) > In other words, ConnectController() should not immediately result in > Snp.Start() being called. Hmm, now that you put it like this, it's hard for me to comment on this specific statement. I'm unsure if the higher level network drivers can do their jobs (i.e. just bind the device) without calling Snp.Start(). I haven't implemented anything higher level than SNP; I'm not sure about MNP etc. internals. I do admit your original point makes a lot more sense to me now. Can you capture a call stack when Snp.Start() is invoked for the very first time (which, IIUC, is a call that should not happen, in your opinion)? Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
