Re: [PATCH v3 1/2] riscv: Introduce support for hardware break/watchpoints
From: Anup Patel
Date: Thu Feb 26 2026 - 08:05:03 EST
On Thu, Feb 26, 2026 at 6:05 PM Conor Dooley <conor@xxxxxxxxxx> wrote:
>
>
>
> On 26 February 2026 11:40:51 GMT, Anup Patel <apatel@xxxxxxxxxxxxxxxx> wrote:
> >On Thu, Feb 26, 2026 at 2:14 PM Conor Dooley <conor@xxxxxxxxxx> wrote:
> >>
> >> On Thu, Feb 26, 2026 at 11:05:14AM +0530, Anup Patel wrote:
> >> > On Wed, Feb 25, 2026 at 2:31 PM Conor Dooley <conor@xxxxxxxxxx> wrote:
> >> > >
> >> > > On Wed, Feb 25, 2026 at 10:33:27AM +0530, Himanshu Chauhan wrote:
> >> > > > On Tue, Feb 24, 2026 at 1:33 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote:
> >> > > > >
> >> > > > > On Tue, Feb 24, 2026 at 09:30:24AM +0530, Himanshu Chauhan wrote:
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > On Mon, Feb 23, 2026 at 3:55 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote:
> >> > > > > > >
> >> > > > > > > On Mon, Feb 23, 2026 at 10:19:17AM +0530, Himanshu Chauhan wrote:
> >> > >
> >> > > > >
> >> > > > > Did you miss the comment at the end about the remaining TODOs?
> >> > > >
> >> > > > No. As I mentioned in the cover letter, the ptrace support is not
> >> > > > implemented here. I am actively working on it and these are
> >> > > > implemented in ptrace work.
> >> > > > The test is done using the perf events directly. The second patch in
> >> > > > this patch set has the test application.
> >> > >
> >> > > Then the patchset should still be marked RFC, since it is not finished.
> >> >
> >> > Wow! let's all of us post only large series (covering multiple features)
> >> > which are difficult to review instead of making life easier for reviewers
> >> > through incremental series which make gradual progress over-time.
> >>
> >> Where did I say don't post it? In fact, marking it RFC *requires*
> >> posting it. Don't put words in my mouth.
> >>
> >
> >Well, I disagree with you suggestion of marking this series as RFC.
> >This series has well defined scope and is based on ratified spec.
> >A series need not cover all possible features to be a regular
> >non-RFC patches.
> >
> >Don't throw your RFC related opinions pointlessly.
>
> It's clearly not pointless when there are unexplained TODOs.
> Seeing to-do items is absolutely sufficient grounds to question them, and when the response doesn't clearly explain why they're okay, my thoughts about RFC are reasonable - even if ultimately they might be incorrect.
Treating series RFC just because there is some future work to be done
is clearly a pointless opinion of yours.
People across kernel subsystem develop features incrementally as
multiple series.
> Instead of being passive aggressive with me, you could have just explained why it was okay.
You started the agression by asking the series to be RFC just based on
your opinion.