On Tue, Feb 03, 2026 at 09:53:04AM -0800, Song Liu wrote:
> 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).
Right, I consider it a power tool, use at your own discretion...
starting at step 2 overwrites the previous step 2.
> > 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)?
fix_patches() would still *conceptually* be part of step 2. But as an
implementation detail (so that it fail fasts with a bad patch), step 2
would be split into two phases: before step 1 and after step 1.
if (( SHORT_CIRCUIT <= 2 )); then
# validate and fix patches
fi
if (( SHORT_CIRCUIT <= 1 )); then
# build orig kernel
fi
if (( SHORT_CIRCUIT <= 2 )); then
# apply patches and build patched kernel
fi
> > 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)?
No, it would still run for -S2, see above.
> 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.
I don't think that's worth the trouble. If you want to change the
patches, re-run step 2. Otherwise, just skip to step 3 or 4 (where the
patch argument just gets ignored). Again, just a power tool for those
of us who are impatient ;-)
--
Josh
