[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023120832-vegan-trustable-f89a@gregkh>
Date: Fri, 8 Dec 2023 06:29:29 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Saeed Mahameed <saeed@...nel.org>
Cc: Aron Silverton <aron.silverton@...cle.com>,
Jakub Kicinski <kuba@...nel.org>,
Jason Gunthorpe <jgg@...dia.com>,
David Ahern <dsahern@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Leon Romanovsky <leonro@...dia.com>,
Jiri Pirko <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>,
Itay Avraham <itayavr@...dia.com>,
linux-kernel@...r.kernel.org, Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver
On Thu, Dec 07, 2023 at 11:02:36AM -0800, Saeed Mahameed wrote:
> I would like to add that debugfs is usually used to expose the driver
> software states, as it evolves and changes with the driver code, but as I
> explained in the other email, it's clearly not a good solution to expose
> arbitrary objects of complex devices, that require interactive and
> selective debug interfaces tailored to the user use-case.
Why not? Remember, the only rule in debugfs is "there are no rules!"
Well, there is one practical one, "do not rely on debugfs for any
functioning system properties", i.e. "if access to debugfs is not
present, or something in debugfs breaks, the kernel should continue to
work just fine with no change in operations". But that's an overall
system-level rule, not a rule for what you can put into debugfs.
Have fun!
greg k-h
Powered by blists - more mailing lists