UEFI News and Commentary

Tuesday, August 27, 2013

UEFI 2.4 Review, Part 4: Require network drivers to return EFI_NO_MEDIA

This is the fourth in a series of articles reviewing the individual changes in the UEFI 2.4 specification. This time, we're looking at the requirement that the EFI_NO_MEDIA error be returned from a wide variety of network related protocols. Typically, EFI_NO_MEDIA indicates that there is no storage media (for disk-related functions) or no cable (for network related functions).

This update requires the low-level networking drivers to produce this error on their implementations of the Transmit() and Receive() functions in the Managed Network Protocol (MNP) and then each of the networking standard drivers that consume this protocol will propagate this error upwards to their callers. So, for example, the IP4/IP6, UDP4/UDP6, TCP4/TCP6 protocols have Transmit() and Receive(), the DHCP4/DHCP6 protocols have Start() and Stop() functions and the MTFTP4/MTFTP6 protocols have ReadFile() and WriteFile(). All of them now can report EFI_NO_MEDIA.

Why? So that calling applications can quickly determine if the cable is removed and decide to take appropriate action. Previously, there was no status code which clearly described this scenario, leaving the caller to try and decide if some sort of timeout had occurred due to a routing issue, or due to the cable not being present. Now the callers can make an intelligent choice.

Strangely, the SIMPLE_NETWORK protocol was not updated, although it is called out in the notes. My feeling is that this was either (a) a mistake or (b) a determination that some existing drivers couldn't handle the updated language.

UEFI is becoming a more capable networking platform all the time. Don't be surprised if higher level networking standards make their appearance soon. Then we'll wonder why we ever booted ;-)

1 comment:

Kappa Tau said...

Re: "Strangely, the SIMPLE_NETWORK protocol was not updated"

An SNP instance has a member called Mode (pointer to EFI_SIMPLE_NETWORK_MODE).

Mode->MediaPresentSupported is allowed to be FALSE. The SNP driver can communicate this way whether the driver (or device) is capable of determining media presence. Being incapable is allowed.

If Mode->MediaPresentSupported is TRUE though, then Mode->MediaPresent carries the media present status from the time of the most recent GetStatus() call.

I believe that people usually write SNP drivers for NICs, not MNP drivers. Edk2 contains an MNP implementation that can sit on top of any SNP. By requiring EFI_NO_MEDIA from MNP drivers only, and upwards, no existing SNP code needs to be changed (which should constitute the overwhelming corpus of UEFI network drivers), just the "central" MNP code needs to look at SNP.Mode->MediaPresent (after GetStatus()) and distinguish EFI_NO_MEDIA.

This is just a guess of course.