[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230426154713.6706865f@gandalf.local.home>
Date: Wed, 26 Apr 2023 15:47:13 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Masami Hiramatsu <mhiramat@...nel.org>, netdev@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 0/2] DSA trace events
On Wed, 26 Apr 2023 22:43:01 +0300
Vladimir Oltean <vladimir.oltean@....com> wrote:
> Instead of living in fear that this might happen, I think what would be
> the most productive thing to do would be to just create a proper API in
> the next kernel development cycle to expose just that information, and
> point other people to that other API, and keep the trace events just for
> debugging.
I also want to add that if a tool does use a trace event that was not your
intention, you can then fix the tool to do it properly.
I had this with powertop. It had hardcoded events (did not use
libtraceevent) and when I modified the layout, it broke, and Linus reverted
my changes. After fixing powertop to do things properly, I was able to get
my changes back in.
So even if you do break user space, you can still fix it later.
-- Steve
Powered by blists - more mailing lists