linux-kernel - Re: [PATCH v2 01/20] rv: Refactor da

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87frc17kus.fsf@yellow.woof>
Date: Thu, 02 Oct 2025 10:45:31 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>, linux-kernel@...r.kernel.org,
 Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, linux-trace-kernel@...r.kernel.org
Cc: Gabriele Monaco <gmonaco@...hat.com>, Tomas Glozar <tglozar@...hat.com>,
 Juri Lelli <jlelli@...hat.com>, Clark Williams <williams@...hat.com>, John
 Kacur <jkacur@...hat.com>
Subject: Re: [PATCH v2 01/20] rv: Refactor da_monitor to minimise macros

Gabriele Monaco <gmonaco@...hat.com> writes:
> The da_monitor helper functions are generated from macros of the type:
>
> DECLARE_DA_FUNCTION(name, type) \
> static void da_func_x_##name(type arg) {} \
> static void da_func_y_##name(type arg) {} \
>
> This is good to minimise code duplication but the long macros made of
> skipped end of lines is rather hard to parse. Since functions are
> static, the advantage of naming them differently for each monitor is
> minimal.
>
> Refactor the da_monitor.h file to minimise macros, instead of declaring
> functions from macros, we simply declare them with the same name for all
> monitors (e.g. da_func_x) and for any remaining reference to the monitor
> name (e.g. tracepoints, enums, global variables) we use the CONCATENATE
> macro.
> In this way the file is much easier to maintain while keeping the same
> generality.
> Functions depending on the monitor types are now conditionally compiled
> according to the value of RV_MON_TYPE, which must be defined in the
> monitor source.
> The monitor type can be specified as in the original implementation,
> although it's best to keep the default implementation (unsigned char) as
> not all parts of code support larger data types, and likely there's no
> need.
>
> We keep the empty macro definitions to ease review of this change with
> diff tools, but cleanup is required.
>
> Also adapt existing monitors to keep the build working.
>
> Signed-off-by: Gabriele Monaco <gmonaco@...hat.com>

Farewell, macros. You won't be missed.

Reviewed-by: Nam Cao <namcao@...utronix.de>