On 3/5/26 9:08 AM, Petr Mladek wrote: > On Wed 2026-03-04 21:03:41, Song Liu wrote: >> On Wed, Mar 4, 2026 at 5:39 PM Joe Lawrence <[email protected]> wrote: >>>>> (Tangent: kpatch-build implemented a unit test scheme that cached object >>>>> files for even greater speed and fixed testing. I haven't thought about >>>>> how a similar idea might work for klp-build.) >>>> >>>> I think it is a good idea to have similar .o file tests for klp-diff >>>> in klp-build. >>>> >>> >>> kpatch-build uses a git submodule (a joy to work with /s), but maybe >>> upstream tree can fetch the binary objects from some external >>> (github/etc.) source? I wonder if there is any kselftest precident for >>> this, we'll need to investigate that. >> >> Ah, right. I forgot that carrying .o files in the upstream kernel is a bit >> weird. That may indeed be a blocker. > > I am afraind that caching .o files in the upstream git tree can't work > in priniple. The upstream tree is generic. But .o files are comparable > only when using the same toolchain, ... > > Or do I miss anything, please? >
Hi Petr, For kpatch-build, the cached object files were placed in a separate repo away from the source code: https://github.com/dynup/kpatch-unit-test-objs/commits/master/ and its purpose is mostly to avoid regressions against known code sequences (i.e. gcc omitting symbol section symbols, clang unnamed sections, static call tests, etc.) It only exercises the binary comparison code and not full livepatch generation, so it never creates or loads any .ko. But you are right that the toolchain, optimization levels, etc. can all contribute to generating unique code sequences. The unit-test-objs were a (huge time) optimization to avoid building kernels just to check things that should be generated 99% of the time -- or perhaps never, given the toolchains we had on hand. For example, we've converted a few user bug reports into unit tests as we didn't have a particular compiler version or kernel config at the ready. It's a nice tool to be able to run a `make unit` test against your development branch and have an answer in a few minutes. The full `make integration` test takes at least a few coffee cups and dog walks to complete :D Hope that clarifies things? Regards, -- Joe
