linux-kernel - Re: [PATCH v9 0/5] rust: DebugFS Bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <DB8BVOLRNDQU.SMTSAMKQ6WVH@kernel.org>
Date: Thu, 10 Jul 2025 13:11:27 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Danilo Krummrich" <dakr@...nel.org>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>
Cc: "Matthew Maurer" <mmaurer@...gle.com>, "Miguel Ojeda"
 <ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>, "Boqun Feng"
 <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "Rafael J. Wysocki"
 <rafael@...nel.org>, "Sami Tolvanen" <samitolvanen@...gle.com>, "Timur
 Tabi" <ttabi@...dia.com>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v9 0/5] rust: DebugFS Bindings

On Thu Jul 10, 2025 at 1:09 PM CEST, Benno Lossin wrote:
> On Thu Jul 10, 2025 at 11:36 AM CEST, Danilo Krummrich wrote:
>> On Thu Jul 10, 2025 at 7:27 AM CEST, Greg Kroah-Hartman wrote:
>>> Ugh.
>>>
>>> Yes we need write.  And read, and custom file-ops, and the like as
>>> that's what debugfs is doing today for C code!  We need this to be as
>>> simple as, or almost as simple as, what we have today in C or no one is
>>> going to use this stuff and go off and attempt to write their own mess.
>>
>> I agree, we really want the helpers you're referring to below. I think we
>> discussed this in previous iterations already.
>>
>>> While I would love to have something as simple as:
>>> 	void debugfs_create_u8(const char *name, umode_t mode, struct dentry *parent, u8 *value);
>>> like we do today.  I understand that this makes all sorts of
>>> "assumptions" that Rust really doesn't like (i.e. lifetime of *value and
>>> the like), BUT we MUST have something like this for Rust users, as
>>> that's going to ensure that people actually use this api.
>>
>> I think it can be as simple as
>>
>> 	void debugfs_create_u8(const char *name, umode_t mode, struct dentry *parent, u8 *value);
>>
>> in Rust as well. Declaring this in a structure looks like this.
>>
>> 	struct Data {
>> 	   counter: File<u8>,
>> 	}
>>
>> Given that we have some Dir instance, this can be as simple as:
>>
>> 	dir.create_file_u8(...);
>>
>> Which uses default callbacks for read(), write(), etc.
>>
>>> Look at an in-kernel function today, like ath9k_init_debug() that
>>> creates a metric-ton of debugfs files and binds them to different
>>> variables that are owned by a structure and more complex data structures
>>> and memory dumps and other random file interactions.  We need, in Rust,
>>> a way to do everything that that function can do today, in a SIMPLE
>>> manner that reads just as easily as ath9k_init_debug() does.
>>
>> That's possible with the current design and code, it misses the helpers, such as
>> create_file_u8() above, to reduce the boilerplate though. With that, it should
>> look pretty similar.
>
> Can't you just implement the traits directly on `u8` and then just call
> `create_file`?

Ah I guess for write support you need `Atomic<u8>` and that doesn't
implement `Display`...

Maybe `Display` is the wrong trait for this...

---
Cheers,
Benno