Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Dependency Graph #44
There is a problem with dependency graph, and it's a big one: modules are very rarely dependent on modules (the only cases are BEFORE and AFTER opcodes). Most of modules are dependent on PPIs/protocols, but there is no easy way to determine what module publish/unpublish/republish a given protocol. There are some easy heuristics like "if the module has protocol GUID inside, but it's not in it's DEPEX section, it's probably publishing it", there are some more complex heuristics, there are disassembler/decompiler engines that can be used to locate calls of RegisterProtocol/NotifyProtocol and similar functions - possibilities are many, but all of them are very hard to automate well enough.
I don't say the feature isn't worth it, but there are many easier things to do right now, like NVRAM parsing/validation and new builder code, so I don't think I can get into DepGraph problem any time soon.
In my experience, even this is not always the case in practice. For example the ThinkPad modules I've worked with often contain many GUIDs inside which are never referenced by the code.