On 9/9/25 16:39, Jinchao Wang wrote:
On 9/9/25 16:00, Masami Hiramatsu (Google) wrote:
On Mon, 8 Sep 2025 13:20:51 +0800
Jinchao Wang <[email protected]> wrote:
...
Yeah, I think not. For one this is an almost verbatim copy of
arch_install_hw_breakpoint() with zero re-use. Surely you've been
taught
better?
I introduced this to modify bp_addr in atomic context in my RFC series.
I thought it was clearer to split the introduction and refactor.
And then It was used in the wprobe series, so I left it as introduced
in the RFC series.
I agree your suggestion is right. I am willing to refactor after
wprobe.
I'm OK to refactor it to reuse arch_install_hw_breakpoint().
My point is to have CONFIG_HAVE_REINSTALL_HW_BREAKPOINT so that
we can easily implement the dependency for other features which
requires this feature in Kconfig level.
And why would we want to export guts like this?
I wanted to introduce a real-time stack corruption debugging tool,
which needs a helper to change bp_addr in atomic context (kprobe
handler).
And wprobe needs it also.
I agree with Peter, it should not expose the architecture
dependent code directly. Instead, we need a wrapper.
Thank you,
Understood, I will use the wrapper instead.
Hi Masami,
I would like to ask for your advice regarding a development workflow issue.
I have a patch series that refactors |arch_reinstall_hw_breakpoint|, which
I know you are using in your |wprobe| series. My new feature,
|kstackwatch|, is
dependent on my patches and also on your wrapper patch for
|modify_wide_hw_breakpoint_local|.
Since we are working on different subsystems with different maintainers,
I am concerned about how to handle the dependencies between our patches
to avoid
introducing trouble.
What is the best practice for this type of cross-subsystem dependency?
Should one of us carry all the patches until they are merged, or is there a
standard procedure for this situation?
Thank you for your guidance.
--
Thanks,
Jinchao
