Method to Support an A Priori

[rogurr]

The reasoning behind not supporting an a priori is valid for an end goal, but we would like to open a discussion on possible workarounds while still using existing C based drivers and code.

We originally thought the first alternative suggested to use file ordering in the FDF would be a viable solution, but the current Patina DXE Core seems to only be updating the internal resource list at the end of each dispatch loop. This means even if a driver publishes a resource the next driver needs, it won't be dispatched until the next loop.

For instance, if 3 drivers listed in the FDF have the following dependency expressions:
Driver 1 -> Depex TRUE
Driver 2 -> Depex Driver 1
Driver 3 -> Depex TRUE
The load order will be Driver 1 -> *Driver 3* -> Driver 2 even though the resources are satisfied.

TianoCore works this way, so it isn't a bug, but it does force the end user to override most drivers in an apriori along with a handful of libraries to remove the DEPEX from all INF files.

David Smith gave a good suggestion of maybe supporting a specific FV GUID that if present, all drivers in it would be dispatched first and in order.

That comes with its own issues and complexity, but I like how it segregates an undesirable practice into its own region that can be enabled/disabled as needed, and it does not rely on something that is not directly documented in the spec (ordering in FDF).

[DavidWSmith]

The FV Depex approach would rely on creating additional FVs, moving certain drivers into those new FVs, and then adding GUIDs to the Depex for all other FVs. For example, if you want the Pcd driver to load first no matter what, you can add it to the only FV with no Depex. The next set of drivers you want to dispatch would need to only have the GUID installed by the Pcd driver in their INF Depex, and they would be placed (in the desired dispatch order), in an FV that had as its Depex the GUID installed by the Pcd driver. Assuming that set of drivers get dispatched, and on the final pass of dispatch from that FV a new GUID is installed, that GUID would be used as Depex for the next FV, and so on for additional FVs. The final result is several FVs, one with no depex that gets dispatched first, and every other FV with some Depex to ensure the FVs are loaded in order, similar to how drivers are loaded in order based on their Depex expressions.

[XiaomeiMiller]

TRUE is no different than the other dependency list. If engineer expect the driver that has dependency evaluated to be true to be dispatched according to the driver sequence, it's better to change the behavior to match the expectation in the DXE core