[go: up one dir, main page]

|
|
Log in / Subscribe / Register

KSplice: Yes, please

KSplice: Yes, please

Posted Dec 19, 2008 13:54 UTC (Fri) by walles (guest, #954)
Parent article: Followups: performance counters, ksplice, and fsnotify

I think there are lots of people who
a) sometimes upgrade their kernels
b) don't like rebooting their systems

So why are people worried that patching of a running kernel wouldn't be used by anybody?

Personally I can't see who *wouldn't* use it, and I'd love to see these patches go in!

//Johan


to post comments

KSplice: Yes, please

Posted Dec 20, 2008 22:18 UTC (Sat) by man_ls (guest, #15091) [Link]

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds