There's no reason to load things like the nvidia driver if all you want to do is offer a choice to kexec into another kernel, which makes things easier - you can continue just using the display environment the firmware set up.
This is true on "IBM compatible" x86 PCs and will continue to be for the foreseeable future, but it's not the case on all platforms. Some of them require graphics drivers to show anything at all, even simple text.
you bet though that as soon as the grub types are forced into userspace they're going to want to do fancy userspace things, like give me a fancy framebuffer driver and the ability to push a shader into the gpu to animate while the second kernel stage boots, etc etc.
the more rope given here, the more will be taken, a rich programming environment of a whole kernel will I'm sure raise temptation to new levels of stuff here, and the natural progression from the shader framebuffer is hand-off to the next kernel stage so it can keep the animation going until wayland starts or whatever. maybe i'm paranoid.
I think you’re missing the broader point I was trying to make by hyperfocusing on 1 example of an issue that can arise from kexec and is solvable in a number of ways. Ultimately the critique raised in the video about focusing on the VM and not trying this on real HW yet is a very real one and is the single hardest problem here I suspect, so punting on it can’t go on for too long.
My broader point is that the majority of kexec issues are associated with the difficulty in quiescing the hardware, and there's simply no need to load the majority of drivers before offering this option which constrains the problem significantly.
Again, I think you’re thinking I’m saying which I’m not. I’m not saying it’s impossible. I’m suggesting the scope of work may be harder than they pitched which is that they have all the pieces and don’t really need to do much other than some packaging & some EFI integration. UDEV changes and kernel patches (more than the trivial 2 they have right now) would prove that the idea requires more work than anticipated.
I don't see any need for kernel patches, and the udev policy is just config rather than code as far as I can tell. Bringing kexec into this is certainly more complicated than not using kexec, but I wouldn't expect (and I do have some familiarity of working with kexec) this to be a lot of engineering work.
I'm more-or-less just a dumb user in these matters, but I've been using Linux to boot Linux with my semi-elaborate desktop rig because that's how ZFSBootMenu[0] do. Keeping [fairly] quiet about unnecessary hardware (like nVidia drivers) during this bootloader phase seems to be doing the trick for me.
Or, at least: I certainly didn't have to do anything to the kernel for it to work. I'm just running whatever Void Linux is rolling with right now.
