site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com It's a two stage operation. Thanks Scott _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I'm pursuing an interesting sub-project that involved porting kexec to darwin. For background, kexec is a Linux tool that is used to boot another kernel/initrd from a Linux OS. kexec usage in the Linux world has been quite interesting, from bypassing slow PC BIOS for a much faster reboot, to a boot into a updated kernel without a reboot cycle, to a jump into a crash dump kernel that can recover from a kernel panic. It's potential benefits under a darwin kernel are quite obvious once one understand the kexec operation. 1st stage involves setting up a "bootloader" code block to load the kernel and then storing the new kernel/initrd/params into a reserved section of ram and setting a reboot hook. This obviously involves a kext to do the heavy lifting in kernel land. 2nd step issues a reboot and when almost to the point of reboot, the kernel hook jumps to the code block that loads the new kernel in that same way as it would be loaded from a real bootloader. The critical point here is to be able to intercept the reboot/shutdown at the last possible safe moment and jump off into the kexec created "bootloader" code block. A kexec from darwin to darwin should be easier as the correct boot params can be easily extracted from the running darwin kernel. A kexec from darwin to Linux is the next easiest as this involves converting darwin boot params into Linux boot params and I already have existing code that does this. A kexec from Linux to darwin is more difficult as the darwin boot params will have to be created from scratch using available Linux resources. The EFI boot params should be easy, creating a proper flat device tree is the complex part. I'm not asking for help on this (yet) but just putting it out for comments and suggestions, pitfalls, etc. This email sent to site_archiver@lists.apple.com
participants (1)
-
Scott D. Davilla