DEPEX section tells DXE dispatcher how one DXE driver is dependent from an other DXE driver or from any number of DXE protocols. Dependency expression (DepEx) is a list of instructions to a very simple stack machine, for example, if your DXE driver needs to be executed before a driver with a given GUID, it’s DepEx section will look like this:
BEFORE {given GUID}
END
If your Driver is using Protocol1, Protocol2 and Protocol3 and so it needs to be executed after all there will be available, it’s DepEx sections will look like this:
PUSH Protocol1Guid
PUSH Protocol2Guid
AND
PUSH Protocol3Guid
AND
END
PUSH opcode has one immediate operand - the GUID, AND opcode gets 2 GUIDs from the stack and puts TRUE (both protocols are already installed) or FALSE (one or both of the protocol is not installed) back to the stack.
For a given driver to be executed in a given round of dispatching, it’s DepEx section must evaluate to TRUE, so if the driver doesn’t depend from anything, it’s DepEx will be like this:
TRUE
END
If the driver needs to be executed by another driver, not by DXE dispatcher, this DepEx will be like this:
FALSE
END
Some drivers need to be executed even before the actual dispatching starts, they are listed in so called AprioriFile, that is a list of GUIDs of DXE drivers to run right after DxeCore without evaluating their DepEx sections.
If a driver doesn’t have DepEx section, it’s the same as if it’s TRUE; END; case, aka execute immediately.
DXE dispatcher will evaluate DepEx sections of all drivers that weren’t executed yet in rounds, if after a given round no more drives were executed, DXE phase ends and DepEx sections aren’t used anymore.
The same concept is used for PEI (instead of protocols, GUIDs of PEI-to-PEI interfaces are used there) and SMM.