Hacker News new | past | comments | ask | show | jobs | submit login

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.



Does the kernel actually support doing that? The pitch is that they already have all the pieces and don’t need to do any kernel work to enable this.


Module loading is handled by udev, so udev merely needs to support enumerating a subset of the hardware to (eg) ensure input devices are available.


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.

[0]: https://docs.zfsbootmenu.org/en/v2.3.x/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: