[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z5rSjsdwG2aonZrB@boqun-archlinux>
Date: Wed, 29 Jan 2025 17:14:54 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: peterz@...radead.org, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org, netdev@...r.kernel.org,
andrew@...n.ch, hkallweit1@...il.com, tmgross@...ch.edu,
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,
anna-maria@...utronix.de, frederic@...nel.org, tglx@...utronix.de,
arnd@...db.de, jstultz@...gle.com, sboyd@...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, tgunders@...hat.com
Subject: Re: [PATCH v9 1/8] sched/core: Add __might_sleep_precision()
On Thu, Jan 30, 2025 at 08:56:44AM +0900, FUJITA Tomonori wrote:
> On Tue, 28 Jan 2025 12:37:38 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
>
> > On Sat, Jan 25, 2025 at 07:18:46PM +0900, FUJITA Tomonori wrote:
> >> Add __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.
> >>
> >> Modify __might_sleep() to call __might_sleep_precision() but the
> >> impact should be negligible. strlen() isn't called in a normal case;
> >> it's called only when printing the error (sleeping function called
> >> from invalid context).
> >>
> >> Note that Location::file() providing a null-terminated string for
> >> better C interoperability is under discussion [1].
> >
> > Urgh :/
>
> Yeah... so not acceptable?
>
I would like to see some concrete and technical reasons for why it's not
acceptable ;-) I'm not sure whether Peter was against this patch or just
not happy about Location::file() providing a null-terminated string is a
WIP.
To me, null-terminated string literals don't provide much benefits
other than you can pass it via only one pointer value, the cost is that
you will always need to calculate the length of the string when needed,
so hard to say it's a straightforward win.
Regards,
Boqun
> Then I switch to the implementation with Rust macros, which gives a
> null terminated string.
Powered by blists - more mailing lists