[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72ndFNw2uDLjOsd1nFjQMFXMHCxAZgUztaq_AR4HA5E-PQ@mail.gmail.com>
Date: Sun, 9 Feb 2025 12:10:44 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Lyude Paul <lyude@...hat.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, rust-for-linux@...r.kernel.org,
Maíra Canal <mairacanal@...eup.net>,
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>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Wedson Almeida Filho <wedsonaf@...il.com>, Mika Westerberg <mika.westerberg@...ux.intel.com>,
Xiangfei Ding <dingxiangfei2009@...il.com>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] rust/kernel: Add faux device bindings
On Fri, Feb 7, 2025 at 11:10 PM Lyude Paul <lyude@...hat.com> wrote:
>
> This is a very good question :), especially because it turns out I actually
> think this function is not thread-safe! Though I don't think that's actually
> much of a problem for Send/Sync here:
>
> So - my original assumption was that since faux_device_destroy() just wraps
> around device_del() and put_device() we'd get thread safety. put_device() is
> thread-safe, but on closer inspection I don't see that device_del() is. It
> _can_ be called from any thread, but only so long as there is a guarantee it's
> called exactly once. I think that's fine both for C and rust, but it
> definitely warrants a more descriptive SAFETY comment from me.
>
> So for the C side of things I might actually add documentation to device_del()
> for this that would look something like this:
Thanks for taking a look -- I am glad I asked (asking is easy... :)
> And then I suppose we could refer back to device_del() in faux_device_destroy()'s
> documentation if we want.
Yeah, the idea was that, since Greg welcomes tweaks on the C side,
then whatever guarantees we use from the C side, if they can be
documented, even better, and it makes it easy to just refer to that
fact.
It should hopefully also make it slightly less likely to drop the
guarantee by mistake on the C side.
On the Rust side, we can even be explicit and say e.g. "..., as
guaranteed/documented by the C API".
Cheers,
Miguel
Powered by blists - more mailing lists