Re: [PATCH v2 2/2] rust: debugfs: avoid transmuting FileOps

From: Matthew Maurer

Date: Fri May 29 2026 - 14:56:11 EST


>
> The approach I have currently is to use debugfs auxiliary data to retain
> the actual callback references. `FileOps` becomes parameterized by both
> the backing data type and the auxiliary data type, and callback
> operations recover their callback value through `debugfs_get_aux()`.
>
> This is not API-neutral. Debugfs exposes one auxiliary pointer, so a
> read-write callback file needs one object containing both retained
> callback references. In the version I have now,
> `read_write_callback_file()` takes a `&'static ReadWriteCallbacks<F, W>`
> instead of two separate callback references. There are no in-tree users
> of that API, but it is still a visible change and may be the wrong
> tradeoff.
>
> Does this seem like a reasonable direction?
>
> Thanks,
> Tamir
>

My first choice would be to just add #[repr(C)], which I believe makes
it safe - having an instance of one of the various structs carries
proof that its callback existed as of creation time, and so the type
is inhabited. We could add an unsafe constructor to make that clearer
if it's not clear as-is. This is an invariant on object existence
(which can be managed dynamically) rather than type existence, which
must be managed statically.

If we want to move to using auxdata, we should move all the way to
auxdata - don't materialize zsts anymore, call the callbacks stored in
the auxdata. You can also convert to function pointers in this case,
because the only reason we were using `F: impl Fn()` was to leverage
the singleton, which shouldn't be necessary anymore, and should
simplify the code.