Hi! > > in terms of hit-patching kernels you are correct. > > > > but that's a far cry from what it sounded like you were demanding > > (that it must handle any kernel patch) > > No, I was not demanding that at all, my suggestion was: > > > My claim is that if a patch is correct/safe in the old fashioned > > way, then a fundamental principle is that a live patching > > subsystem must either safely apply, or safely reject the live > > patching attempt, independently from any user input. > > Note the 'if'. It could start simple and stupid, and only allow cases > where we know the patch must be trivially safe (because it does not do > much in terms of disturbing globally visible state). That needs some > tooling help, but apparently tooling help is in place already.
Actually, even if patch is very trivial, it will be difficult to determine if it is safe. Consider adding error check: int do_something(void) { #if 0 if (1) return -1; #endif return 0; } void main(void) { if (do_something()) printf("error happened\n"); } Imagine changing that #if 0 to #if 1. But gcc at -O3 already optimized out the error message. So... do we compile whole second kernel and compare the binaries? I think I seen remark "don't try to do binary compares" somewhere... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/