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.
Hi Everyone,
Thanks for your support during GSoC application process.
I realize that i didn’t have valuable contributions to HAIKU before applying, which likely affected my chances.
I’m planning to continue contributing over the coming months and build strong technical skills.
Yes, as you mention, the GSoC application process requires submitting at least one change to the code on Gerrit, which, as far as I can see, you have not done. You are of course welcome to continue participating in Haiku and starting to make some changes. Then you can be ready for next year.
This happened to me as well: my first GSoC application in 2008 was rejected. But I kept working on Haiku anyway, and applied again in 2009, with a little more experience, a better project idea, and some patches already merged. And it worked much better the second time.
Also, maybe kexec is not the easiest subjet to start with. I wouldn’t know where to start myself, not even being familiar with how it works at all on Linux. Maybe outside of GSoC you can start by working on smaller/simpler tasks first, and then take on larger challenges as you get more understanding of the code.
