OSNews

My biggest concern is whether it can detect those cases and abort/perform a normal reboot rather than fail silently.

Trust me.. the failure won't be silent .

I don't think it will fail "silently" in such a case (more like kernel panic).

Actually no. It just means you need to have functionality that can serialize and deserialize the structures in a manner both the old kernel and new kernel understand.

The ONLY time you need to fully reboot (as you suggest) is when certain hardware needs replaced and is not hot-swappable or when hardware needs to re-initialize and it cannot be done on the fly. But that is a hardware limitation.

There is NO software limitation to needing to reboot. Any software limitation can be removed from being a limitation by proper design of the functionality.

OK, in theory you do serialize and deserialize everything, but in the real world it can be in some cases so complex that doing it in a bug free manner is not worth the effort.

That is why I wrote significantly.

Actually no. It just means you need to have functionality that can serialize and deserialize the structures in a manner both the old kernel and new kernel understand. "

In this case a programmer needs to write code to convert the old structures into the new structures (which isn't the same as converting the structure/s into some common format that both kernels understand). Of course in some cases this conversion would be impossible, because you can't create data out of nothing.



Wrong. Their own paper (called "Ksplice: Automatic Rebootless Kernel Updates") says:

"5.2 Capturing the CPUs to update safely

A safe time to update a function is when no thread’s instruction pointer falls within that function’s text in memory and when no thread’s kernel stack contains a return address within that function’s text in memory.
Ksplice uses Linux’s stop machine facility to achieve an appropriate opportunity to check the above safety condition for every function being replaced. When invoked, stop machine simultaneously captures all of the CPUs on the system and runs a desired function on a single CPU.
If the above safety condition is not initially satisfied, then Ksplice tries again after a short delay. If multiple such attempts are unsuccessful, then Ksplice abandons the upgrade attempt and reports the failure.
Ksplice’s current implementation therefore cannot be used to automatically upgrade non-quiescent kernel functions. A function is considered non-quiescent if that function is always on the call stack of some thread within the kernel. For example, the primary Linux scheduler function, schedule, is non-quiescent since sleeping threads block in the scheduler. This limitation does not prevent Ksplice from handling any of the significant Linux security vulnerabilities from May 2005 to May 2008."

I'd also point out that they only talk about security patches; and nowhere do they mention patches for any other purpose (e.g. new device drivers, switching to a different scheduler, changing the USB stack, etc). With this in mind I expect it won't be useful for any major kernel changes - e.g. it might handle a change from "2.6.28-r5" to "2.6.28-r6", but might not handle a change from "2.6.28-r6" to "2.6.29-r1", and also might not handle changes to most compile time options. My theory here is that if it did handle this properly they would have bragged about it, instead of only mentioning security patches.

- Brendan