It is in src/tests/system/boot/loader
1 Like
Hi, I’ve been working on my proposal and just finished a draft. I’ve shared the PDF could you please review it when you get some time? Your feedback would really help me improve it.
https://docs.google.com/document/d/1lTayudCXS59HnxYeSkuZjP1rfIeXQLdSgGub-DHLl9c/edit?usp=drivesdk
Hello sir @PulkoMandy
Thank you so much for the detailed review and feedback on my proposal! I have updated my GSoC application document to reflect all of your suggestions. Here is a summary of the design choices and changes I’ve made based on your comments:
Early document : Early document
New document : New proposal with suggested changes
Changes suggested by u
1. Why a core subsystem instead of a kernel module (src/add-ons/kernel)? I’ve updated the proposal to clarify this choice. I decided against a loadable module because kexec requires deep, direct access to the core kernel infrastructure (vm/, smp/, arch/x86/) to permanently shut down secondary CPUs, disable interrupts, and manipulate CPU state to perform the final jump. Exposing stable module interfaces for all of this would add unnecessary complexity. Additionally, kexec needs to be available even when the system is in a degraded state (e.g., switching to a new kernel for debugging), so relying on the module loading infrastructure would be risky. Finally, tearing down the running kernel is an irreversible, system-wide operation, which is fundamentally different from typical add-on functionality. (Linux also implements kexec in the core kernel for these reasons).
2. Syscall Naming Conventions Good catch on the naming conventions! I have updated the text to use the kern_kexec_load and kern_kexec_execute prefixes for the userspace API, and _user_kexec_load and _user_kexec_execute for the kernel-side handlers, acknowledging that this is enforced by Haiku’s syscall generation tools.
3. Splitting responsibilities between userspace and kernel space You raised a great point about moving parts to userspace. I have updated the design so that a userspace tool (similar to Linux’s kexec-tools) will handle reading the kernel ELF image, parsing/validating its headers, and preparing the image data in a buffer. It will then pass this unprepared data to the kernel via kern_kexec_load. The kernel implementation will be strictly limited to operations that require privilege: reserving safe memory, shutting down CPUs, and executing the jump.
4. Design Choice: Bootloader vs. Direct Jump & kernel_args I agree that trying to do both approaches is unnecessary. I have made a firm design choice to proceed with the direct kernel jump approach. To solve the challenge of preparing the complex kernel_args structure in RAM (since we won’t have the bootloader to build it from scratch), my plan is to capture and clone the kernel_args from the currently running host kernel at the time of the kexec call. Since most of the hardware and memory layout remains unchanged, I can use the existing structure as a base and only modify the fields that change (like the new entry point).
5. Graceful System Teardown (Quitting apps, flushing disks) I completely agree. I have updated the “Deliverables” and “Timeline” sections to reflect this. The initial June prototype will focus purely on the raw CPU jump kexec loop. However, the July/August timeline is now specifically dedicated to “Graceful System Teardown & Polish” which includes implementing logic to safely quit userspace applications, sync/unmount disks, and ensure hardware is in a safe idle state before the transition.
6. Experimental Timeline I’ve rewritten the June/early July timeline to remove the rigid “high-level” steps. It is now framed as an “Iterative Prototyping Phase” centered around an Experimental Loop: attempting the CPU jump, analyzing serial crash dumps to see what breaks, adjusting the CPU/memory state teardown, and repeating until the entry point is reached.
7. “FreeBSD” Reference & Gerrit Links I clarified the FreeBSD reference I was advised by mentors on IRC earlier this month to study FreeBSD’s kexec implementation as an alternative architectural reference alongside Haiku’s, so I added a note to it . I have also reformatted the “Previous Contributions” section to include the dynamic Gerrit query link (https://review.haiku-os.org/q/owner:257kishan@gmail.com) as you suggested.
Thank you again for the incredibly helpful direction. I’ve incorporated all of this into the latest version of the proposal. Let me know if you have any additional thoughts!
1 Like
Hi, I applied for GSoC 2026 with a kexec proposal for Haiku. I wasn’t selected, but I’d appreciate any feedback on what I could improve (design, clarity, contributions). I’m still interested in contributing. any guidance would help. Thanks!
2 Likes