[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <willemdebruijn.kernel.14cd8a5376059@gmail.com>
Date: Wed, 03 Sep 2025 13:13:52 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Breno Leitao <leitao@...ian.org>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Clark Williams <clrkwllms@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-rt-devel@...ts.linux.dev,
kernel-team@...a.com,
efault@....de,
calvin@...nvd.org
Subject: Re: [PATCH 3/7] netpoll: Move netpoll_cleanup implementation to
netconsole
Breno Leitao wrote:
> On Tue, Sep 02, 2025 at 06:49:26PM -0400, Willem de Bruijn wrote:
> > Breno Leitao wrote:
> > > Shift the definition of netpoll_cleanup() from netpoll core to the
> > > netconsole driver, updating all relevant file references. This change
> > > centralizes cleanup logic alongside netconsole target management,
> > >
> > > Given netpoll_cleanup() is only called by netconsole, keep it there.
> > >
> > > Signed-off-by: Breno Leitao <leitao@...ian.org>
> >
> > What's the rationale for making this a separate patch, as the
> > previous patch also moves the other netconsole specific code from
> > netpoll.c to netconsole.c?
>
> I just tried to isolate the changes in small patches as possible.
> previous functions needed to go all together, given it was they were in
> a chain.
>
> this one netpoll_cleanup() is more independent, so, I decided to
> separate it, making the patches smaller individually.
Sounds good. Thanks for clarifying.
> > And/or consider updating prefix from netpoll_.. to netconsole_..
>
> Good point, and I agree with the feedback.
>
> In cases like this, should I rename the function while moving, or,
> adding an additional patch to rename them?
In general, it helps review when move patches are entirely NOOPs.
In this specific case, if this is the only case that gets renamed
*and* it is such a small patch *and* it is a revision of an earlier
patch that has already been verified to be a NOOP, then by exception
it's also fine to squash.
If there are more renames, it might be best to bundle them in a single
(otherwise NOOP, again) patch at the end of the series?
Powered by blists - more mailing lists