linux-kernel - Re: [RFC PATCH 01/17] 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: <5e122c0ed80fb57223f4630d0d83186a110bf056.camel@redhat.com>
Date: Mon, 25 Aug 2025 10:02:33 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Nam Cao <namcao@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, 
 Masami Hiramatsu <mhiramat@...nel.org>, linux-trace-kernel@...r.kernel.org,
 Tomas Glozar <tglozar@...hat.com>,  Juri Lelli <jlelli@...hat.com>, Clark
 Williams <williams@...hat.com>, John Kacur <jkacur@...hat.com>
Subject: Re: [RFC PATCH 01/17] rv: Refactor da_monitor to minimise macros

On Thu, 2025-08-21 at 10:49 +0200, Gabriele Monaco wrote:
> On Thu, 2025-08-21 at 10:14 +0200, Nam Cao wrote:
> 
> > > +#define RV_AUTOMATON_NAME CONCATENATE(automaton_, MONITOR_NAME)
> > > +#define EVENT_MAX CONCATENATE(event_max_, MONITOR_NAME)
> > > +#define STATE_MAX CONCATENATE(state_max_, MONITOR_NAME)
> > > +#define events CONCATENATE(events_, MONITOR_NAME)
> > > +#define states CONCATENATE(states_, MONITOR_NAME)
> > 
> > I think these macros make it harder to read the code. E.g. it is
> > not obvious what is "events" in "enum events event".
> > 
> > How about renaming these to be the same for all monitors, and get
> > rid of these 4 macros?
> > 
> > Something like
> > 
> > 	enum states_wip -> enum da_states
> > 	state_max_wip   -> da_state_max
> > 	etc
> > 
> > Just my preference, of course. You probably have your reasons for
> > doing it this way?

I had more thoughts on this and I guess at least these enums might need
to stay as they are.

I'm working on a patch to write some sort of unit test for monitors,
where I inject events and see that the errors are triggered.
For readability that requires the events definitions and, currently,
I'm putting all those tests in the same file. It looks simpler to keep
the enums different.

But of course any suggestion is welcome.
Thanks,
Gabriele