[ added live-patching@ ML as well, in consistency with Josh ] On Sun, 22 Feb 2015, Ingo Molnar wrote: > It's all still tons of work to pull off a 'live kernel upgrade' on > native hardware, but IMHO it's tons of very useful work that helps a > dozen non-competing projects, literally. Yes, I agree, it might be nice-to-have feature. The only issue with that is that it's solving a completely different problem than live patching. Guys working on criu have made quite a few steps in that direction of already course; modulo bugs and current implementation limitations, you should be able to checkpoint your userspace, kexec to a new kernel, and restart your userspace. But if you ask the folks who are hungry for live bug patching, they wouldn't care. You mentioned "10 seconds", that's more or less equal to infinity to them. And frankly, even "10 seconds" is something we can't really guarantee. We could optimize the kernel the craziest way we can, but hardware takes its time to reinitialize. And in most cases, you'd really need to reinitalize it; I don't see a way how you could safely suspend it somehow in the old kernel and resume it in a new one, because the driver suspending the device might be completely different than the driver resuming the device. How are you able to provide hard guarantees that this is going to work? So all in all, if you ask me -- yes, live kernel upgrades from v3.20 to v3.21, pretty cool feature. Is it related to the problem we are after with live bug patching? I very much don't think so. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
