From: Simon Horman <horms@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH net-next 2/7] netconsole: refactor CPU number formatting into separate function
Date: Tue, 25 Feb 2025 14:08:13 +0000 [thread overview]
Message-ID: <20250225140813.GU1615191@kernel.org> (raw)
In-Reply-To: <20250225-diamond-gaur-of-anger-b0f77e@leitao>
On Tue, Feb 25, 2025 at 03:09:20AM -0800, Breno Leitao wrote:
> Hello Simon,
>
> On Tue, Feb 25, 2025 at 10:17:48AM +0000, Simon Horman wrote:
> > On Fri, Feb 21, 2025 at 05:52:07AM -0800, Breno Leitao wrote:
> > > Extract CPU number formatting logic from prepare_extradata() into a new
> > > append_cpu_nr() function.
> > >
> > > This refactoring improves code organization by isolating CPU number
> > > formatting into its own function while reducing the complexity of
> > > prepare_extradata().
> > >
> > > The change prepares the codebase for the upcoming taskname feature by
> > > establishing a consistent pattern for handling sysdata features.
> > >
> > > The CPU number formatting logic itself remains unchanged; only its
> > > location has moved to improve maintainability.
> > >
> > > Signed-off-by: Breno Leitao <leitao@debian.org>
> > > ---
> > > drivers/net/netconsole.c | 18 +++++++++++-------
> > > 1 file changed, 11 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> > > index c086e2fe51f874812379e6f89c421d7d32980f91..26ff2ed4de16bce58e9eeaf8b5b362dfaafaca0a 100644
> > > --- a/drivers/net/netconsole.c
> > > +++ b/drivers/net/netconsole.c
> > > @@ -1117,13 +1117,21 @@ static void populate_configfs_item(struct netconsole_target *nt,
> > > init_target_config_group(nt, target_name);
> > > }
> > >
> > > +static int append_cpu_nr(struct netconsole_target *nt, int offset)
> > > +{
> > > + /* Append cpu=%d at extradata_complete after userdata str */
> > > + return scnprintf(&nt->extradata_complete[offset],
> > > + MAX_EXTRADATA_ENTRY_LEN, " cpu=%u\n",
> > > + raw_smp_processor_id());
> > > +}
> > > +
> > > /*
> > > * prepare_extradata - append sysdata at extradata_complete in runtime
> > > * @nt: target to send message to
> > > */
> > > static int prepare_extradata(struct netconsole_target *nt)
> > > {
> > > - int sysdata_len, extradata_len;
> > > + int extradata_len;
> > >
> > > /* userdata was appended when configfs write helper was called
> > > * by update_userdata().
> > > @@ -1133,12 +1141,8 @@ static int prepare_extradata(struct netconsole_target *nt)
> > > if (!(nt->sysdata_fields & SYSDATA_CPU_NR))
> > > goto out;
> > >
> > > - /* Append cpu=%d at extradata_complete after userdata str */
> > > - sysdata_len = scnprintf(&nt->extradata_complete[nt->userdata_length],
> > > - MAX_EXTRADATA_ENTRY_LEN, " cpu=%u\n",
> > > - raw_smp_processor_id());
> > > -
> > > - extradata_len += sysdata_len;
> > > + if (nt->sysdata_fields & SYSDATA_CPU_NR)
> > > + extradata_len += append_cpu_nr(nt, nt->userdata_length);
> >
> > Hi Breno,
> >
> > As this is the only caller of append_cpu_nr() I'm wondering
> > if it would be nicer if nt was the only argument to append_cpu_nr().
>
> Yes, I can do it. I just kept both functions the same:
>
> static int append_taskname(struct netconsole_target *nt, int offset)
> static int append_cpu_nr(struct netconsole_target *nt, int offset)
>
> Another option is to use extradata_len as the second argument, instead
> of nt->userdata_length. That might(?) make the code easier to read? it
> would look like the following:
>
> extradata_len = nt->userdata_length;
> if (nt->sysdata_fields & SYSDATA_CPU_NR)
> extradata_len += append_cpu_nr(nt, extradata_len);
> if (nt->sysdata_fields & SYSDATA_TASKNAME)
> extradata_len += append_taskname(nt, extradata_len);
>
> What would you write yourself?
I think that I would reduce the number of parameters of append_cpu_nr() and
append_taskname(). But really, any of the options, including this patch
as-is, are fine. So please chose whichever you think is best.
next prev parent reply other threads:[~2025-02-25 14:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 13:52 [PATCH net-next 0/7] netconsole: Add taskname sysdata support Breno Leitao
2025-02-21 13:52 ` [PATCH net-next 1/7] netconsole: prefix CPU_NR sysdata feature with SYSDATA_ Breno Leitao
2025-02-25 10:19 ` Simon Horman
2025-02-21 13:52 ` [PATCH net-next 2/7] netconsole: refactor CPU number formatting into separate function Breno Leitao
2025-02-25 10:17 ` Simon Horman
2025-02-25 11:09 ` Breno Leitao
2025-02-25 14:08 ` Simon Horman [this message]
2025-02-21 13:52 ` [PATCH net-next 3/7] netconsole: add taskname to extradata entry count Breno Leitao
2025-02-25 10:20 ` Simon Horman
2025-02-21 13:52 ` [PATCH net-next 4/7] netconsole: add configfs controls for taskname sysdata feature Breno Leitao
2025-02-25 10:20 ` Simon Horman
2025-02-25 11:41 ` Paolo Abeni
2025-02-25 13:12 ` Breno Leitao
2025-02-21 13:52 ` [PATCH net-next 5/7] netconsole: add task name to extra data fields Breno Leitao
2025-02-25 10:19 ` Simon Horman
2025-02-25 11:17 ` Breno Leitao
2025-02-25 11:53 ` Paolo Abeni
2025-02-25 13:11 ` Breno Leitao
2025-03-04 14:23 ` Paolo Abeni
2025-02-25 14:10 ` Simon Horman
2025-02-21 13:52 ` [PATCH net-next 6/7] netconsole: docs: document the task name feature Breno Leitao
2025-02-25 10:20 ` Simon Horman
2025-02-21 13:52 ` [PATCH net-next 7/7] netconsole: selftest: add task name append testing Breno Leitao
2025-02-25 10:21 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250225140813.GU1615191@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.