updating the kernel without rebooting.

01000101 · Post by **01000101** » Sun Jun 08, 2008 1:58 pm

Hey, I've been thinking about implementing a way to compile my kernel on my dev machine, and (over ethernet) update my live kernel on my test machines without having to restart the PC.

One method I've been looking into was to recieve the kernel binary in a custom packet format, write it to HDD over the existing one and jump to a static area in memory that will re-start the kernel without 'restarting' the pc. But one main issue with that is, once i re-load the kernel off the HDD, the code that was loading the OS may not be in the same spot as it was before the update thus probably causing a triplefault. is there a way for me to do this from a static function address that wont get overwritten each time?

The other method I was thinking about was to take the kernel from the ethernet and put it into its own seperate area, and leave the live one where it is as well, and then jump to the new area and erase the old area, but that is a very wasteful (memory) way to do it and not my first choice.

any ideas?

proxy · Post by **proxy** » Sun Jun 08, 2008 4:11 pm

I've have thought about this before and there is no simple answer. It will not be a simple task, but possibly doable. There are a few things that I believe must be done.

First thing that must be done, is you need to put all threads/processes into a suspended state. Obviously with the exception of the thread which is performing the switch.

You will need some mechanism which allows you to transfer all the kernel level structures representing the system state (processes, threads, file handles, etc).

Both of these things will need to be done VERY carefully, RAM state will be particularly sensitive.

After that, you can hopefully load the new kernel into memory (hard disk is kinda besides the point, doesn't matter until reboot) and hopefully resume all of your suspended processes/threads.

That is unless you are looking to simply update the kernel and plan to reset all processes state. In which case the task should be a bunch easier.
Just look at the kexec system call in linux.

Good luck!

proxy

01000101 · Post by **01000101** » Sun Jun 08, 2008 4:16 pm

I think I might do it a bit simpler.

I'm thinking about loading the update_kernel into memory after the live kernel, then switch to that kernel, and copy that kernel once more to overwrite the older kernel, erase the first copy and resume from the second copy.

Alboin · Post by **Alboin** » Sun Jun 08, 2008 4:25 pm

I don't know if this has any relevance, but Erlang touts its ability to dynamically upgrade its programs. You might be able to look into that and see how it does it. (Granted, it will be on a different level than an OS, but....why not?)

Good Luck.

bewing · Post by **bewing** » Sun Jun 08, 2008 4:37 pm

Updating the kernel on-the-fly is called a "patch", and there are lots of OSes than can accomodate them without a reboot. The question is: how small, and how modular is your kernel/OS? ... And especially whether you are actually changing the formats of any system tables.

01000101 · Post by **01000101** » Sun Jun 08, 2008 7:58 pm

My OS is not modular at all. It is about 60k compiled and is one giant binary. I don't wish to patch, i wish to replace lol. I just want to replace the live kernel with a newer version.

Dex · Post by **Dex** » Sun Jun 08, 2008 8:31 pm

I can see very little problems, why do you not just replace the kernel off the hdd with new one, then do a

Code: Select all

        mov ax,201h
        mov bx,7c0h
        mov cx,1
        mov dx,80h
        push bx
        xor bx,bx
        pop es
        int 13h
        jmp 0:7c00h

or

Code: Select all

;Warm Boot By Dex (untested)
        xor   ax,ax            ;*SET FLAG FOR WARM REBOOT*
        mov   ds,ax            ; dos flags memory segment address
        mov   si,0x0472        ; dos reboot type flag offset
        mov   cx,0x1234        ; warm boot indicator
        mov   word[ds:si],cx   ; set the flag

                               ;*WARM REBOOT*
        db    0xea             ; Machine language to jump to
                               ; address FFFF:0000 (reboot)
        dw    0x0000
        dw    0xffff           ; No return required
       			       ; we're rebooting!

        jmp $		       ; Just incase ;-)

As you kernel is run from memory, so replacing the kernel on hdd is no problem.

01000101 · Post by **01000101** » Sun Jun 08, 2008 8:34 pm

wow lol. thanks for making me feel like an idiot =).

that solves the issue entirely. thanks.

Kay · Post by **Kay** » Mon Jun 09, 2008 6:13 am

I'd recommend checking out a working model, namely the Linux kernel's 'kexec' syscall.

Userland component
Kernel land component