Re: [PATCH 2/5] rust: sync: add const constructor for raw_spinlock_t

["Gary Guo" <gary@garyguo.net>]

On Tue Jul 7, 2026 at 2:17 PM BST, Alice Ryhl wrote:
> On Wed, Jul 01, 2026 at 05:15:55PM +0100, Gary Guo wrote:
>> On Tue Jun 23, 2026 at 4:38 PM BST, Alice Ryhl wrote:
>> > The abstractions for pr_*_ratelimited! need to construct a global
>> > `struct ratelimit_state`, which contains a `raw_spinlock_t` field. Thus,
>> > add a const constructor for the `raw_spinlock_t` type.
>> >
>> > The SPINLOCK_OWNER_INIT constant isn't mirrored via a const helper
>> > because bindgen generates a 'static mut' instead of a constant from the
>> > pointer constant.,
>> >
>> > The __ARCH_SPIN_LOCK_UNLOCKED constant cannot be translated by bindgen
>> > because it's a define for a struct without type annotations, so it's
>> > explicitly declared in Rust.
>> >
>> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>
>> > +/// Helper for creating a raw unlocked `bindings::raw_spinlock_t`.
>> > +///
>> > +/// For use in statics containing raw spinlocks.
>> > +pub const fn raw_spin_lock_unlocked(name: &'static CStr) -> bindings::raw_spinlock_t {
>> 
>> These functions (incl. raw_lockdep_map) should really be private functions.
>
> Hmm, I think there could be cases where a driver needs to interact with
> C code directly where this is useful. Even if use from drivers is
> discouraged, I don't think we need to go out of our way to prevent it.
> It's like the bindings crate.

I think a theoretical use case is not a justification for exporting such
low-level functions. If such need arises, we can export them by then.

Best,
Gary