On Tue, Feb 3, 2026 at 8:45 AM Joe Lawrence <[email protected]> wrote: [...] > > Or at least validate_patches() could be replaced with > > check_unsupported_patches(), as the apply/revert test wouldn't be needed > > since the actual apply/revert would happen immediately after that in > > fix_patches(). > > > > Currently fix_patches runs in short-circuit step (2) after building the > original kernel. But what if the user runs: > > $ klp-build -T 0001.patch > $ klp-build -S 2 0002.patch
On one hand, I think this is a user mistake that we need the users to avoid by themselves. If the user do $ klp-build -T 0001.patch $ klp-build -S 3 0002.patch Even when 0001.patch and 0002.patch are totally valid, the end result will be very confusing (it is the result of 0001.patch, not 0002). > If we move fix_patches() to step (1) to fail fast and eliminate a > redundant apply/revert, aren't we then going to miss it if the user > jumps to step (2)? > > Is there a way to check without actually doing it if we're going to > build the original kernel first? > > And while we're here, doesn't this mean that we're currently not running > validate_patches() when skipping to step (2)? On the other hand, I guess we can always run fix_patches. If any -S is given, we compare the fixed new patches against fixed saved patches. If they are not identical, we fail fast. Thanks, Song
