(2014/05/06 21:26), Steven Rostedt wrote: > On Tue, 06 May 2014 20:45:50 +0900 > Masami Hiramatsu <masami.hiramatsu...@hitachi.com> wrote: > > >> However, I also think if users can accept such freezing wait-time, >> it means they can also accept kexec based "checkpoint-restart" patching. >> So, I think the final goal of the kpatch will be live patching without >> stopping the machine. I'm discussing the issue on github #138, but that is >> off-topic. :) >> > > I agree with Ingo too. Being conservative at first is the right > approach here. We should start out with a stop_machine making sure that > everything is sane before we continue. Sure, that's not much different > than a kexec, but lets take things one step at a time.
Agreed. that is a correct way to move things forward. Anyway, my stop_machine-less approach still has many implementation issues. It should be solved in upstream, not out-of-tree. So, this topic is off-topic at this stage. :) We need to focus on how to merge live-patch into upstream kernel. > ftrace did the stop_machine (and still does for some archs), and slowly > moved to a more efficient method. kpatch/kgraft should follow suit. Sure, that's a best story of how things should be evolved on the kernel :) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
