This series provides safe DebugFS bindings for Rust, with a sample
driver using them.

The primary intended way to use these bindings is to attach a data
object to a DebugFS directory handle, and use the contents of that
attached object to serve what's inside the directory. Through a
combination of pinning and equivariance, we can ensure that the pointers
in the attached object will remain valid until after the DebugFS
directory is made inaccessible.

Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
Matthew Maurer (8):
      rust: debugfs: Bind DebugFS directory creation
      rust: debugfs: Bind file creation for long-lived Display
      rust: debugfs: Add scoped builder interface
      rust: debugfs: Allow subdir creation in builder interface
      rust: debugfs: Support format hooks
      rust: debugfs: Implement display_file in terms of fmt_file
      rust: debugfs: Helper macro for common case implementations
      rust: samples: Add debugfs sample

 MAINTAINERS                     |   2 +
 rust/bindings/bindings_helper.h |   1 +
 rust/helpers/dcache.c           |  12 +
 rust/helpers/helpers.c          |   1 +
 rust/kernel/debugfs.rs          | 514 ++++++++++++++++++++++++++++++++++++++++
 rust/kernel/lib.rs              |   1 +
 samples/rust/Kconfig            |  11 +
 samples/rust/Makefile           |   1 +
 samples/rust/rust_debugfs.rs    | 120 ++++++++++
 9 files changed, 663 insertions(+)
---
base-commit: b6a7783d306baf3150ac54cd5124f6e85dd375b0
change-id: 20250428-debugfs-rust-3cd5c97eb7d1

Best regards,
-- 
Matthew Maurer <mmaurer@google.com>

On 4/29/25 4:15 PM, Matthew Maurer wrote:
> This series provides safe DebugFS bindings for Rust, with a sample
> driver using them.

Adding Timur Tabi, because he was looking into how to do this.


thanks,
John Hubbard

> 
> The primary intended way to use these bindings is to attach a data
> object to a DebugFS directory handle, and use the contents of that
> attached object to serve what's inside the directory. Through a
> combination of pinning and equivariance, we can ensure that the pointers
> in the attached object will remain valid until after the DebugFS
> directory is made inaccessible.
> 
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
> Matthew Maurer (8):
>        rust: debugfs: Bind DebugFS directory creation
>        rust: debugfs: Bind file creation for long-lived Display
>        rust: debugfs: Add scoped builder interface
>        rust: debugfs: Allow subdir creation in builder interface
>        rust: debugfs: Support format hooks
>        rust: debugfs: Implement display_file in terms of fmt_file
>        rust: debugfs: Helper macro for common case implementations
>        rust: samples: Add debugfs sample
> 
>   MAINTAINERS                     |   2 +
>   rust/bindings/bindings_helper.h |   1 +
>   rust/helpers/dcache.c           |  12 +
>   rust/helpers/helpers.c          |   1 +
>   rust/kernel/debugfs.rs          | 514 ++++++++++++++++++++++++++++++++++++++++
>   rust/kernel/lib.rs              |   1 +
>   samples/rust/Kconfig            |  11 +
>   samples/rust/Makefile           |   1 +
>   samples/rust/rust_debugfs.rs    | 120 ++++++++++
>   9 files changed, 663 insertions(+)
> ---
> base-commit: b6a7783d306baf3150ac54cd5124f6e85dd375b0
> change-id: 20250428-debugfs-rust-3cd5c97eb7d1
> 
> Best regards,

On Tue, Apr 29, 2025 at 11:15:54PM +0000, Matthew Maurer wrote:
> This series provides safe DebugFS bindings for Rust, with a sample
> driver using them.
> 
> The primary intended way to use these bindings is to attach a data
> object to a DebugFS directory handle, and use the contents of that
> attached object to serve what's inside the directory.

That's cool, but really, not the common use for debugfs.  Why not make
the "simple" way work first (i.e. just create/remove directories and
files attached to variables and generic read/write functions) and then,
if really needed, we can add the structure layout mess like you are
wanting to do here.

And yes, I know why you want to tie debugfs layout to a structure
layout, it makes one type of debugfs use really easy to write in rust,
but that's not the common user for what we have today.  Let's address
the common use first please, save the "builder" pattern stuff for after
we nail all of that down.

thanks,

greg k-h

> And yes, I know why you want to tie debugfs layout to a structure
> layout, it makes one type of debugfs use really easy to write in rust,
> but that's not the common user for what we have today.  Let's address
> the common use first please, save the "builder" pattern stuff for after
> we nail all of that down.
>
> thanks,
>
> greg k-h

I'll remove that API in the next version of the patch series to get
the basics down first, but to give some motivation to what I was
trying to support which *is* done in C today, see qcom-socinfo [1] -
it uses a backing `socinfo_params` struct which is expected to outlive
its whole directory structure.

[1]: https://github.com/torvalds/linux/blob/b6ea1680d0ac0e45157a819c41b46565f4616186/drivers/soc/qcom/socinfo.c#L133-L156

On Wed, Apr 30, 2025 at 08:01:38AM -0700, Matthew Maurer wrote:
> > And yes, I know why you want to tie debugfs layout to a structure
> > layout, it makes one type of debugfs use really easy to write in rust,
> > but that's not the common user for what we have today.  Let's address
> > the common use first please, save the "builder" pattern stuff for after
> > we nail all of that down.
> >
> > thanks,
> >
> > greg k-h
> 
> I'll remove that API in the next version of the patch series to get
> the basics down first, but to give some motivation to what I was
> trying to support which *is* done in C today, see qcom-socinfo [1] -
> it uses a backing `socinfo_params` struct which is expected to outlive
> its whole directory structure.

What exactly do you mean by "outlive"?  Right now debugfs has no way to
"own" a structure and it just "has to work" so that the file will always
be there and hope that the backing variable is also still there.  I
guess you are trying to encode that "hope" into something real?  :)

> [1]: https://github.com/torvalds/linux/blob/b6ea1680d0ac0e45157a819c41b46565f4616186/drivers/soc/qcom/socinfo.c#L133-L156
> 

Yes, SOC drivers are a mess of debugfs files, but manually creating them
is "fine" to start with, let's not go wild to start with.  If we see
common patterns outside of the single soc driver use case, then we can
propose exporting structures as a directory structure in debugfs, but I
really think that is a very minor use of the api at the moment.

thanks,

greg k-h

On Wed, Apr 30, 2025 at 8:21 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Apr 30, 2025 at 08:01:38AM -0700, Matthew Maurer wrote:
> > > And yes, I know why you want to tie debugfs layout to a structure
> > > layout, it makes one type of debugfs use really easy to write in rust,
> > > but that's not the common user for what we have today.  Let's address
> > > the common use first please, save the "builder" pattern stuff for after
> > > we nail all of that down.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I'll remove that API in the next version of the patch series to get
> > the basics down first, but to give some motivation to what I was
> > trying to support which *is* done in C today, see qcom-socinfo [1] -
> > it uses a backing `socinfo_params` struct which is expected to outlive
> > its whole directory structure.
>
> What exactly do you mean by "outlive"?  Right now debugfs has no way to
> "own" a structure and it just "has to work" so that the file will always
> be there and hope that the backing variable is also still there.  I
> guess you are trying to encode that "hope" into something real?  :)

Yes, the `Values` structure used by the builder interface enforces
that the backing variable must live at least as long as the `Dir`
corresponding to the lowest directory it's going to be used in. To
make DebugFS safe in Rust, we either need to:
1. Have DebugFS files own things (not currently done, doesn't seem to
match intentions).
2. Expose things that live forever (e.g. globals, like the early patches do)
3. Have a pinned structure that is guaranteed to outlive the files
that use it (what the builder interface is trying to support)

>
> > [1]: https://github.com/torvalds/linux/blob/b6ea1680d0ac0e45157a819c41b46565f4616186/drivers/soc/qcom/socinfo.c#L133-L156
> >
>
> Yes, SOC drivers are a mess of debugfs files, but manually creating them
> is "fine" to start with, let's not go wild to start with.  If we see
> common patterns outside of the single soc driver use case, then we can
> propose exporting structures as a directory structure in debugfs, but I
> really think that is a very minor use of the api at the moment.
>
> thanks,
>
> greg k-h

On Wed, Apr 30, 2025 at 08:24:14AM -0700, Matthew Maurer wrote:
> On Wed, Apr 30, 2025 at 8:21 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Apr 30, 2025 at 08:01:38AM -0700, Matthew Maurer wrote:
> > > > And yes, I know why you want to tie debugfs layout to a structure
> > > > layout, it makes one type of debugfs use really easy to write in rust,
> > > > but that's not the common user for what we have today.  Let's address
> > > > the common use first please, save the "builder" pattern stuff for after
> > > > we nail all of that down.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > I'll remove that API in the next version of the patch series to get
> > > the basics down first, but to give some motivation to what I was
> > > trying to support which *is* done in C today, see qcom-socinfo [1] -
> > > it uses a backing `socinfo_params` struct which is expected to outlive
> > > its whole directory structure.
> >
> > What exactly do you mean by "outlive"?  Right now debugfs has no way to
> > "own" a structure and it just "has to work" so that the file will always
> > be there and hope that the backing variable is also still there.  I
> > guess you are trying to encode that "hope" into something real?  :)
> 
> Yes, the `Values` structure used by the builder interface enforces
> that the backing variable must live at least as long as the `Dir`
> corresponding to the lowest directory it's going to be used in. To
> make DebugFS safe in Rust, we either need to:
> 1. Have DebugFS files own things (not currently done, doesn't seem to
> match intentions).

Agreed, let's not do that.

> 2. Expose things that live forever (e.g. globals, like the early patches do)

Let's start with this for now.

> 3. Have a pinned structure that is guaranteed to outlive the files
> that use it (what the builder interface is trying to support)

Let's add this "after" we get the basics down.  Should make things
simpler for you to work on now, and for us to review.

Baby steps :)

thanks,

greg k-h