Hi Huacai,

Thank you for raising this -- I take the concern seriously, and I'd like
to lay out the full history so everyone is working from the same facts.

> 2. ... Wang Yuli had already alerted you in your v1. At that point, you
> had two options: a) abandon your own patches ... or b) thank Wang Yuli
> for the reminder and assistance, then seek to collaborate on
> development. However, you did neither

I did take option (b). Wang Yuli's v1 messages were code review, and I
thanked him on-list and folded every point into v2:

  https://lore.kernel.org/all/[email protected]/

  "Thanks for the review -- all three points are addressed in v2. ...
   You were right that this had not been properly exercised before ..."

His "awM is dangerous, see how x86 did" comment in particular led
directly to the ANNOTATE_DATA_SPECIAL rework that is in the series now.
The review made these patches better and I'm grateful for it.

> 1. Wang Yuli released his version first; re-releasing it without any
> prior communication is simply rude.

On priority: this series is not a fork of Wang Yuli's. I have been
carrying LoongArch livepatch tooling since kpatch, which is klp-build's
predecessor (same maintainer, later folded into the kernel). My kpatch
LoongArch support was posted on 2024-12-05 and merged 2026-01-12:

  https://github.com/dynup/kpatch/pull/1427

developed over several review rounds with Joe Lawrence. When Josh
announced the kpatch -> klp-build transition, he listed the LoongArch
port as coming from me:

  https://github.com/dynup/kpatch/issues/1498
  ("loongarch ... shared by @georgejguo below, coming soon")

So this klp-build series is the continuation of my own earlier work,
not a takeover of someone else's.

On scope: Wang Yuli's own suggestion in v1 was to use his patch to
replace "these two patches" -- i.e. the basic arch-enablement piece.
This series is the objtool/klp-diff and build-tooling integration
(12 patches), including four fixes Joe found by running the full
klp-build flow end to end. The overlap is just the arch-enablement part.

> does that mean Wang Yuli can now throw yours in the trash when he
> releases his v2?

I don't see this as anyone's to throw away -- it's shared work toward
the same goal, and I'd much rather converge than duplicate. Concretely:
I'm happy to fold the overlapping arch-enablement patch in with Wang
Yuli as author (or Co-developed-by), and to work with him on the rest.

Wang Yuli, if you're up for it, let's coordinate -- I can take the
objtool/klp-diff pieces and we land one clean series together.

Thanks,
George

Reply via email to