[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251023.142442.2120786567125816704.fujita.tomonori@gmail.com>
Date: Thu, 23 Oct 2025 14:24:42 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: dakr@...nel.org
Cc: 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 2/2] rust: Add read_poll_count_atomic function
On Tue, 21 Oct 2025 14:35:34 +0200
"Danilo Krummrich" <dakr@...nel.org> wrote:
>> +pub fn read_poll_count_atomic<Op, Cond, T>(
>
> I understand why you renamed the function, but read_poll_timeout_atomic() would
> still be accurate -- it does perform a timeout in every iteration. Let's keep
> the original name please.
Ok, I'll revert the name.
>> + mut op: Op,
>> + mut cond: Cond,
>> + delay_delta: Delta,
>> + count: usize,
>
> Maybe retry would be a slightly better fit compared to count. If we want to be a
> bit more verbose, I suggest retry_count. :)
Sure, I'll go with 'retry'.
Powered by blists - more mailing lists