* Pavel Machek <pa...@ucw.cz> wrote:
> 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...
Fair enough.
Thanks,
Ingo
--
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/
