linux-kernel - Re: [PATCH v10 17/19] rv: Add rtapp

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 for Android: free password hash cracker in your pocket

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

Message-ID: <309ecabeacc72f13de7b190f37423f1aeafe991d.camel@redhat.com>
Date: Wed, 02 Jul 2025 08:29:28 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>, Nam Cao <namcao@...utronix.de>
Cc: linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	john.ogness@...utronix.de
Subject: Re: [PATCH v10 17/19] rv: Add rtapp_sleep monitor

On Tue, 2025-07-01 at 17:17 -0400, Steven Rostedt wrote:
> On Tue, 1 Jul 2025 23:03:38 +0200
> Nam Cao <namcao@...utronix.de> wrote:
> > 
> > > Bonus points if it shows how it was generated so that people will
> > > know
> > > how to regenerate it.  
> > 
> > If it's okay, not in this series. It requires changes to the RV
> > core
> > script, and I prefer not touching things which are not LTL-specific
> > for
> > now, unless necessary. The DA monitors and the containers do not
> > have it as
> > well.
> 
> Yeah, just update this set to state that this code was generated.
> 
> > 
> > Let me stash it into my TODO list of RV cleanups. I will add this
> > for LTL,
> > deterministic automaton and container in one go.
> 

That's a good point, at the moment the DA monitors have a comment in
the /completely/ generated files (the automata header), the others
where just a skeleton is prepared have some hints that we removed while
filling the monitor.

I'd say for now it's good to just add a comment in the LTL header (like
Dot2k:fill_model_h_header), then we can adapt all generated files
(whether fully or not) to have also the actual command that generated
them starting from the model file.
Or did you have something different in mind, Nam?

Anyway this is all well documented, so pointing to the documentation
like we do in the header doesn't look bad to me.

Thanks,
Gabriele