[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72nhWy5V=bE+39jFvV20+2v-xp+4iYmG=qTt+=GgF6Z3hA@mail.gmail.com>
Date: Thu, 6 Apr 2023 18:45:36 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Wedson Almeida Filho <wedsonaf@...il.com>,
Greg KH <gregkh@...uxfoundation.org>,
rust-for-linux@...r.kernel.org, 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>,
linux-kernel@...r.kernel.org,
Wedson Almeida Filho <walmeida@...rosoft.com>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
On Wed, Apr 5, 2023 at 10:49 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> Oh man, that's sad, I was hoping it would write the equivalent inline
> function in rust.
Some of us hope Rust would directly handle importing C headers, so
avoiding the intermediate step, like a few languages support.
> But yeah, feel free to convert macros to inline functions where the
> difference is moot. There is indeed no real reason for mutex_lock() to
> not be an inline function in that case.
We initially minimized changes on the C side on purpose, but if
maintainers are OK with that (modulo exceptions), it would be great.
Cheers,
Miguel
Powered by blists - more mailing lists