On Fri, 16 May 2014, Steven Rostedt wrote: > Why I still favor the stop_machine approach, is because the method of > patching is a bit simpler that way. A "lazy" approach will be more > complex and more likely to be buggy. The thing I'm arguing here is not > the end result being a problem, but the implementation of the patching > itself causing bugs.
Well, what can I say to this. 21 files changed, 594 insertions(+), 10 deletions(-) that's a complete implementation, including comments and some documentation. Yes, it still has TODOs (such as patching modules as they are modprobed, we're working on multi-arch support, etc), but it's more or less complete working x86 skeleton. > I rather have a "lazy" approach, I'm glad to hear that, thanks :) > but like ftrace and its breakpoint method, the stop_machine approach is > the simpler way to make sure the patching works before we try to > optimize it. I am still not convinced that it's more complex. It's actually lazy both in the way it performs patching and in implementation -- we basically set a flag, flip the switch, and let the universe converge to a new state by itself. It's basically hard to argue about level of bugginess when no actual bugs are being pointed out :) (well, yes, the kthreads stuff needs to be taken care of, but both kgraft and kpatch have similar issues there). Thanks, -- Jiri Kosina SUSE Labs -- 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/