[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37795dc7-a121-b30b-76de-1ba6dd705c5e@ryhl.io>
Date: Sat, 15 Jul 2023 10:14:57 +0200
From: Alice Ryhl <alice@...l.io>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
asahi@...ts.linux.dev, Asahi Lina <lina@...hilina.net>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
John Stultz <jstultz@...gle.com>,
Stephen Boyd <sboyd@...nel.org>,
Josh Stone <jistone@...hat.com>,
Gaelan Steele <gbs@...ishe.com>,
Heghedus Razvan <heghedus.razvan@...tonmail.com>
Subject: Re: [PATCH v2] rust: time: New module for timekeeping functions
On 7/15/23 03:17, Thomas Gleixner wrote:
> On Fri, Jul 14 2023 at 16:55, Asahi Lina wrote:
>> +ktime_t rust_helper_ktime_get_real(void) {
>> + return ktime_get_real();
>> +}
>> +EXPORT_SYMBOL_GPL(rust_helper_ktime_get_real);
>
> Colour me confused. But why does this need another export?
>
> This just creates yet another layer of duct tape. If it's unsafe from
> the rust perspective then wrapping it into rust_"unsafe_function" does not
> make it any better.
>
> Why on earth can't you use the actual C interfaces diretly which are
> already exported?
Currently, you can't call inline C functions directly from Rust. So we
wrap them in non-inline functions for now.
It's something we definitely want to fix, but it hasn't been fixed yet.
Alice
Powered by blists - more mailing lists