If I may, I would like to say something about kexec.
It is not to criticise kexec, that probably works perfectly, it is just about one use case: booting a different kernel release.
Let's imagine yesterday kernel managing yesterday device.
That yesterday device has some configuration bits labelled "do not touch", i.e. bits that you should write to the same value that you read them.
Having "do not touch" bits in configuration words is a usual way to plan for extensibility, those bits are currently zero, but in future (backward compatible) version of the device they may have a meaning, like enabling the super-duper new function.
So yesterday kernel behaves perfectly well, preserving the value of the "do not touch" bits, and obviously do not have the driver of the super-duper function.
Back to today, I have currently booted the today kernel, which knows how to drive the super-duper function, and because it has recognised the more powerful today's device, it has enabled the super-duper function in the device by setting the previously "do not touch" bit (now enable super-duper function bit) to the device register.
Now, if I kexec yesterday's kernel, it will not change the "do not touch" bit, but it does not have the super-duper function driver neither.
I am not saying this pattern happens often, I am not saying the system will always misbehave, I am just saying there is a risk.