The way the question in the title is framed might be of general interest.
The concrete problem or example that this question should be applied to is: Finding the optimal solution to hack an otherwise dead MacBook Pro (burned out AMD discrete graphics chip) back into usable condition.
Current situation: fried dGPU, boot has to be forced into iGPU always. With default hardware settings and default system installation the machine will simply not boot.
Unwanted side-effect for disabling the dGPU in software: AMDRadeonX3000.kext mustn't load immediately, if it does – boot hangs on Yosemite, freezes in Sierra and results in quickly forced reboots due to overheating in High Sierra before the GUI is up. Symptoms observable in Sierra, last line in verbose boot is:
IOConsoleUsers IOScreenLockState 3.
Not loading the kext at all: thermal management for AMD chip gets out of hand. Temperature never sinks below 65°C and easily spikes higher despite the chip not being used.
Delayed loading: All is OK an the temperature side. GPU isn't idling at full power but idling at a much lower powerstate. Depending on OS version the sensors report temperatures ranging from 0°C–60°C. Although that reading seems not really realistic or trustworthy the whole unit also stays cooler to the touch.
But "all is well" only most of the time. Every now and then there are very rare sleep issues on Sierra, and alas: every time on Yosemite.
Finding that the kext needs to be loaded for running the machine but is better not loaded (in the delayed manner at least) for sleeping the machine: an attempt to
kextunload the seemingly responsible kext results in an immediate panic. This one paragraph is mainly of concern when on Yosemite but not so much on Sierra.
On top of that it may not be the optimal solution. Thermal management needs 1-2 minutes in the current configuration after loading the kext to stabilise into acceptable levels. Therefore the desire to rotate the kexts and see what might give best results.
Steps taken so far:
One of the graphics driver kexts in Sierra needs to be loaded at/around/after boot, automatically, but later.
They are interdependent of course and all loaded as deemed necessary by the system under normal circumstances.
But the system will hang on boot if the one kext in question is loaded too early and the system runs exactly as desired if it is loaded later.
In this case I confirmed that loading it either manually or together with a GUI login via hooks works.
However, this means that placing the kext in
/Library/Extensions results in the hang on boot as they are consulted too early.
What also does not work is using system wide launchd agents or daemons since these are also consulted too early. Same daemons under user-hierarchies do apparently not have the necessary privileges to load a kext.
So where has this one kext from /System/Library/Extensions to go? How can a delay be enforced that this kext is only loaded after all its up or down dependencies have been loaded?
"Which kext?" you might ask. This question is about all the AMD kexts, each to be tested individually.
This is in an attempt to further improve this guide.
Main question: How can one of those graphics kexts be forced to a delayed load? (Other than the LoginHook method.)
If this proves suboptimal for the stated goal, it would be also nice, or even better to know:
Are there other ways in software to keep the disabled dGPU under the thermal and power management rules of the system? (The less power goes through this unsused chip the better.)
That case may involve other kernel extensions as well.