On Fri, Apr 26, 2019 at 11:00:48AM +0200, Miroslav Benes wrote: > > - For binary-based patch generation (kpatch-build), we currently diff > > objects at a per-compilation-unit level. That would have to be > > changed to work on vmlinux.o instead. > > > > - Objtool would also have to be changed to work on vmlinux.o. It's > > currently not optimized for large files, and the per-.o whitelisting > > would need to be fixed. And there may be other issues lurking. > > > > Also, thinking about objtool in this context has given me another idea, > > which might allow us to get rid of the use of -flive-patching and > > -fdump-ipa-clones altogether (which are both nasty and way too > > compiler-dependent): > > > > Since objtool is already reading every function in the kernel, it could > > create a checksum associated with each function, based on all the > > instructions (both within the function and any alternatives or other > > special sections it relies on). The function checksums could be written > > to a file. > > > > Then, when a patch file is applied and the kernel rebuilt, the checksum > > files could be compared to determine exactly which functions have > > changed at a binary level. > > > > Thoughts? Any reasons why that wouldn't work? > > I think it could work. If nothing else, it would give us the information > we look for. I'm gone next week but after that I'll start looking at implementing this. > > And, if we wanted to take the idea even further, objtool could have the > > ability to write the changed functions to a new object file. Voila, we > > now pretty much have kpatch-build :-) (Though whether this is better > > than source-based patch generation is certainly an open question.) > > ...worth of discussion. When I get some free time I might prototype something to see what it would look like. -- Josh
