This article is the fourteenth in a series looking over the changes introduced in the UEFI 2.4 specification. This time we take a look at the new support for interruptible driver diagnostics.
The Driver Diagnostics protocol, in its current form, has been around since the UEFI 2.0 specification. The earlier version, found in the EFI specification, was identical other than the way in which supported languages were listed in the SupportedLanguages protocol member. So this protocol has been around a while, and a number of drivers already support it.
But some types of diagnostics don't finish quickly. In fact, some may take quite a long time to complete. When a diagnostics application or the built-in setup application in the firmware tries to use these, it would like to provide some sort of status indicator to show that, in fact, the diagnostics still continue. In addition, some managing diagnostic applications can use timers to detect when a device's diagnostic function has hung to give control back to the user. But it is hard for these applications to detect the difference between a really long diag run and a hang.
The UEFI 2.4 specification helps with this. First, it allows a device's diagnostic function (RunDiagnostics()) to return the EFI_NOT_READY status code, indicating that diagnostics have begun and are on-going. A managing diagnostic application that receives this error code can continue to call the RunDiagnostics() function over and over again, until the function either returns another error or returns EFI_SUCCESS. But at least it knows that the diagnostics have not hung.
In addition, a new DiagnosticType (EfiDriverDiagnosticTypeCancel) allows the managing application to cancel an on-going diagnostic. So, if the user hits Ctrl-C to break, and the managing diagnostic application knows that there is work on-going, it can tell the driver to terminate the diagnostic activity cleanly.
These simple changes in the UEFI 2.4 specification make providing device driver diagnostic capability more robust and responsive.