KSplice: Yes, please
Posted Dec 20, 2008 22:18 UTC (Sat) by man_ls
In reply to: KSplice: Yes, please
Parent article: Followups: performance counters, ksplice, and fsnotify
I think there are two problems here. For desktop systems the biggest issue is stability: if a live-patched kernel is going to be less stable, then people are not going to like it; distributions will probably disable ksplice just in case and it will slowly rot.
Meanwhile, for servers there is the added issue of predictability. To diagnose any problems you want to know for sure the exact state of a system. After a few months of live patching it is hard to know which code is running, so it will add noise to any problem-solving efforts on these machines. The safest course of action is again to disable it, and that is what server distros will probably do.
The inherent coolness of ksplice is big, but before it hits big time it has to meet at least three requirements:
- stability: live-patched kernel must be rock solid,
- predictability: the state of a patched kernel must be exactly like a fresh one, or at least as well defined,
- and accountability: there has to be tools to audit the exact state of the kernel.
Until then it is IMHO best left alone.
to post comments)