I’ve been working on building a small x86-64 OS from scratch to better understand kernel internals, paging, and boot mechanisms. Through this, i have gained hands on with c and assembly.
Recently, I’ve started studying the kexec in Linux and tracing. I’m interested to understanding how the kernel transitions execution to a new image and how memory is prepared for that jump.
I may move step by step, but I’m consistent, I learn by reading code, experimenting, debugging, and building things. I’m comfortable working at the low level and I’m eager to learn my understanding by contributing with mentor guidance.
Is it important to you to understand kexec specifically? Or did you want to contribute to Haiku?
Haiku is not based on linux and therefore has no linux-specific kernel functionality like kexec.
It seems the linux kernel themselves are also participating in gsoc (or atleast the linux foundation is? Maybe not quite the same thing)
You may have missed that one of our GSoC project ideas is about adding something similar to Linux’s kexec to Haiku.
So, just to clarify: in Haiku we don’t use Linux as a kernel, we have our own. But we’d like to be able to do something similar to Linux’s kexec. Studying how Linux does it may be a good start but I expect there will be some differences. For example, our kernel is not “self starting” as much as Linux, and expects quite a few things to be already set up (typically be the bootloader)
You should probably get in touch with @korli for this specific idea.
Personally I do not think that kexec is useful feature on Haiku. Haiku is not server OS that need live kernel reload. Firmware startup time is small on modern computers and virtual machines so it will not significantly speed up reboot.
It is hard to implement it correctly. Kernel may depend of environment (initialized hardware etc.) provided by firmware (BIOS/UEFI) and after reloading kernel on already running OS environment will be undefined that may break hardware drivers.
I understand the concern about firmware initialized hardware state and driver stability.
My goal is mostly educational and architectural exploration. If this feature isn’t aligned with Haiku’s direction, I’d appreciate guidance on other kernel level work where I can contribute.
There will always be people unhappy with one or another feature. I assume korli suggested this idea because he identified a need for it in his own workflow, or maybe he has later plans for it. He can surely work with you to refine the idea and explain what he wants to use it for.
