[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250422143145.GC15651@noisy.programming.kicks-ass.net>
Date: Tue, 22 Apr 2025 16:31:45 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
ojeda@...nel.org, alex.gaynor@...il.com, gary@...yguo.net,
bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
a.hindborg@...sung.com, aliceryhl@...gle.com, tmgross@...ch.edu,
dakr@...nel.org, mingo@...hat.com, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, pmladek@...e.com
Subject: Re: [PATCH v2 0/2] add Rust version of might_sleep()
On Tue, Apr 22, 2025 at 07:30:05AM -0700, Boqun Feng wrote:
> On Fri, Apr 11, 2025 at 07:56:21AM +0900, FUJITA Tomonori wrote:
> > This patchset adds Rust version of might_sleep().
> >
> > These patches were previously part of the IO polling patchset [1], but
> > they were split out to make upstreaming easier.
> >
> > The first patch is for sched/core, which adds
> > __might_sleep_precision(), rust friendly version of __might_sleep(),
> > which takes a pointer to a string with the length instead of a
> > null-terminated string. Rust's core::panic::Location::file(), which
> > gives the file name of a caller, doesn't provide a null-terminated
> > string. __might_sleep_precision() uses a precision specifier in the
> > printk format, which specifies the length of a string; a string
> > doesn't need to be a null-terminated. Providing a null-terminated
> > string for better C interoperability is under discussion [2].
> >
> > The second patch adds a Rust implementation of might_sleep(), on top
> > of the changes in the first patch.
> >
> > [1]: https://lore.kernel.org/lkml/20250220070611.214262-1-fujita.tomonori@gmail.com/
> > [2]: https://github.com/rust-lang/libs-team/issues/466
> >
> > v2:
> > - improve SAFETY comment
> > v1: https://lore.kernel.org/lkml/20250406110718.126146-1-fujita.tomonori@gmail.com/
> >
>
> @scheduler, if there is no objection, I'm going to take these two into a
> pull request to tip soon. Thanks!
Yeah, go ahead. I still think Rust should be fixed, but sure, we can
live with this until that time.
Powered by blists - more mailing lists