[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72m+uAWyRf6y6vAKjCQnwsMqVVGQx3VrHW1yAp4a-5eWew@mail.gmail.com>
Date: Tue, 21 Oct 2025 16:39:37 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, aliceryhl@...gle.com,
daniel.almeida@...labora.com, a.hindborg@...nel.org, alex.gaynor@...il.com,
ojeda@...nel.org, anna-maria@...utronix.de, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, frederic@...nel.org, gary@...yguo.net,
jstultz@...gle.com, linux-kernel@...r.kernel.org, lossin@...nel.org,
lyude@...hat.com, rust-for-linux@...r.kernel.org, sboyd@...nel.org,
tglx@...utronix.de, tmgross@...ch.edu
Subject: Re: [PATCH v2 1/2] rust: add udelay() function
On Tue, Oct 21, 2025 at 2:08 PM Danilo Krummrich <dakr@...nel.org> wrote:
>
> However, if we want to consider it an error if an out of range value is given,
> we should just return a Result. (A simple out of range condition, that can be
> handled by the user easily shouldn't result into a potential WARN()).
I think most callers that will hit this are just buggy, and C is EB
(or worse, UB) as well here, so `Result` isn't great.
I agree that a compile-time one is best, since many (most?) cases will
be constants anyway, so we should definitely have that and avoid
calling the runtime one as much as possible.
Now, for runtime values, since random drivers will call this with
possibly computed values based on who knows what, a warn once may be
too much. A debug assert instead would be less risky if it makes
people more comfortable.
Cheers,
Miguel
Powered by blists - more mailing lists