[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0faa958ef9cc4b834a5ecdc92acd89520f522d44.camel@redhat.com>
Date: Mon, 04 Aug 2025 13:18:33 -0500
From: Crystal Wood <crwood@...hat.com>
To: Costa Shulyupin <costa.shul@...hat.com>, Steven Rostedt
<rostedt@...dmis.org>, Tomas Glozar <tglozar@...hat.com>, John Kacur
<jkacur@...hat.com>, Eder Zulian <ezulian@...hat.com>, Dan Carpenter
<dan.carpenter@...aro.org>, Jan Stancek <jstancek@...hat.com>,
linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH v2] tools/rtla: Consolidate common parameters into
shared structure
On Sat, 2025-07-26 at 10:24 +0300, Costa Shulyupin wrote:
> timerlat_params and osnoise_params structures contain 15 identical
> fields.
>
> Introduce a common_params structure and move those fields into it to
> eliminate the code duplication and improve maintainability.
>
> Signed-off-by: Costa Shulyupin <costa.shul@...hat.com>
FWIW I have a bigger consolidation patchset in the works, that merges a
lot of the codepaths as well as having everything use osnoise_params
(with some members being tool-specific, indicated by comments). If you
want, I could rebase that on this and use container_of() to for tool-
specific params... but then that adds complexity with the top and hist-
specific params, most of which are common between timerlat and osnoise
(and not merged by this patch). So we might want to just keep it simple
with one big struct.
Any thoughts?
> diff --git a/tools/tracing/rtla/src/utils.h b/tools/tracing/rtla/src/utils.h
> index a2a6f89f342d..4c99a3746380 100644
> --- a/tools/tracing/rtla/src/utils.h
> +++ b/tools/tracing/rtla/src/utils.h
> @@ -59,6 +59,32 @@ struct sched_attr {
> };
> #endif /* SCHED_ATTR_SIZE_VER0 */
>
> +/*
> + * common_params - Parameters shared between timerlat_params and osnoise_params
> + */
> +struct common_params {
I'm not sure that util.h makes sense for this... it's pretty core rtla
stuff rather than helper utilities. I'd just put it in osnoise.h (or a
new common.h if we want to keep the actual-osnoise-tracer stuff
separate, though currently it's a jumble).
Do we have any naming conventions for the actual osnoise tracer as
opposed to the broader osnoise family? I don't know if it's likely
we'll ever try to put something outside the osnoise family to rtla, but
if we do "common" could be a bit too generic. Not sure if that's worth
worrying about at this point. Certainly better than using "osnoise" for
both without clarifying.
-Crystal
Powered by blists - more mailing lists