Eugene, > > Yeah. When I was drafting the UDP APP to test the new fix, I found the > > same case you mentioned. We must issue another UDP Configure () to > > clean the previous state once the Ip4Mode.IsConfigured is TRUE. So, > > the above example is not accurate with my the current > > implementation:(. But I'm still not recommend to loop the UDP > > configuration every time if Ip4Mode.IsConfigured is false. The right > > behavior for UDP/TCP is 1) timer check the Ip4Mode.IsConfigured, 2) > > Once Ip4Mode.IsConfigured is TRUE, reconfigure the instance again. > > Sorry for the above example was troubling you. Also use UDP as > > example, correct as below: > > Can't we just call this a defect and make it so the first Configure() that > returns > IsConfigured=TRUE works? It seems much safer to handle this in the stack > than to expect hundreds or thousands of different network applications and > services to try to implement this sequence correctly. > > I don't see where in the UEFI spec it states that you must call Configure(cfg) > Configure(NULL) Configure(cfg) just to make it work...
For the Spec or API itself part, I can't deem the current implementation of Configure() as a defect. EFI_NO_MAPPING means the configuration is not finished yet due to the underlying driver unavailable. So, from the point of view of those Configure() APIs, the up caller should recall the Configure() again until EFI_SUCCESS returned. I thought we could call the corresponding UDP.GetModeData() to know UDP itself configured data (not the underlying driver state), but EFI_NOT_STARTED is returned directly if it's not configured properly. I think it's easy to update the implementation to avoid those sequence calling, but the behavior changed, which will affect many existing application/up caller. So, let's keep the current implementation. > > Thanks, > > Eugene > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
