Eugene, It looks like the code has an assumption that when receive such a ConfigRequest string, it must has one varstore which will generate this ConfigRequest, also has an config access protocol to process this varstore. Can you give some info when this case will raise? Why the original DriverHandle for this device path can be found?
Thanks, Eric -----Original Message----- From: edk2-devel [mailto:[email protected]] On Behalf Of Cohen, Eugene Sent: Wednesday, December 02, 2015 7:42 AM To: [email protected] Subject: [edk2] HII ConfigRouting Assert - Why? In the HiiDatabaseDxe driver there's an ASSERT that seems oddly placed to me: if (IsEfiVarStore) { // // Call the GetVariable function to extract settings. // Status = GetConfigRespFromEfiVarStore(This, EfiVarStoreInfo, ConfigRequest, &AccessResults, &AccessProgress); FreePool (EfiVarStoreInfo); } else { // // Call corresponding ConfigAccess protocol to extract settings // Status = gBS->HandleProtocol ( DriverHandle, &gEfiHiiConfigAccessProtocolGuid, (VOID **) &ConfigAccess ); ASSERT_EFI_ERROR (Status); Status = ConfigAccess->ExtractConfig ( ConfigAccess, ConfigRequest, &AccessProgress, &AccessResults ); } Why is this an ASSERT as opposed to a returned error? Since the DriverHandle can be obtained through a device path fallback mechanism (LocateDevicePath earlier) it seems possible that we just pick up a driver that is not prepared to support HII config access. Should this be changed to return an error or is the ASSERT really what we expect in this situation? And in a release we will just fall through and dereference an uninitialized pointer which is even worse. Thanks, Eugene _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
