[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250701175826.429a7b4b@batman.local.home>
Date: Tue, 1 Jul 2025 17:58:26 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Gabriele Paoloni <gpaoloni@...hat.com>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, mathieu.desnoyers@...icios.com,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
acarmina@...hat.com, chuck.wolber@...ing.com
Subject: Re: [RFC PATCH 1/2] tracing: fixes of ftrace_enable_fops
On Fri, 20 Jun 2025 15:26:27 +0200
Gabriele Paoloni <gpaoloni@...hat.com> wrote:
> I think that from my side I do not have comprehensive answers to all your
> questions (I need to read the code more in depth).
> So to be pragmatic I can split this effort into two parts (documentation and
> redesign); I will propose documentation first with the TIPs that you mentioned
> above and later, if we find a better re-design solution, we can also amend
> the documentation as needed.
Just to confirm, I agree with Masami. The enable file is quite special,
and I don't see the use of user space playing tricks with it, which
even includes lseek. Maybe to keep rewinding a read to get a new status
change?
But it usually contains a single character (sometimes two) and a new
line. It's not something that's ever been reported as an issue. I
rather not touch it if it hasn't been reported as broken because
there's some hypothetical use case that can see it as broken.
Documenting its current behavior is perfectly fine with me.
-- Steve
Powered by blists - more mailing lists