OSDev.org

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?

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

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.

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.

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.

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.

I can see very little problems, why do you not just replace the kernel off the hdd with new one, then do a or As you kernel is run from memory, so replacing the kernel on hdd is no problem.

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

that solves the issue entirely. thanks.

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

Userland component
Kernel land component