linux-kernel - Re: [PATCH v1 2/2] rust: Add read_poll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250814.153951.1907355400690553428.fujita.tomonori@gmail.com>
Date: Thu, 14 Aug 2025 15:39:51 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: acourbot@...dia.com
Cc: fujita.tomonori@...il.com, a.hindborg@...nel.org,
 alex.gaynor@...il.com, ojeda@...nel.org, aliceryhl@...gle.com,
 anna-maria@...utronix.de, bjorn3_gh@...tonmail.com, boqun.feng@...il.com,
 dakr@...nel.org, 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, daniel.almeida@...labora.com,
 me@...enk.dev
Subject: Re: [PATCH v1 2/2] rust: Add read_poll_timeout functions

On Wed, 13 Aug 2025 11:56:26 +0900
"Alexandre Courbot" <acourbot@...dia.com> wrote:

> On Mon Aug 11, 2025 at 1:10 PM JST, FUJITA Tomonori wrote:
>> Add read_poll_timeout functions which poll periodically until a
> 
> "functions" should be the singular "function" as this patch only adds
> one function.

Oops, thanks. I'll fix.

> <snip>
>> +/// # Examples
>> +///
>> +/// ```no_run
>> +/// use kernel::io::Io;
>> +/// use kernel::time::{poll::read_poll_timeout, Delta};
>> +///
>> +/// const HW_READY: u16 = 0x01;
>> +///
>> +/// fn wait_for_hardware<const SIZE: usize>(io: &Io<SIZE>) -> Result<()> {
>> +///     // The `op` closure reads the value of a specific status register.
>> +///     let op = || -> Result<u16> { io.try_read16(0x1000) };
>> +///
>> +///     // The `cond` closure takes a reference to the value returned by `op`
>> +///     // and checks whether the hardware is ready.
>> +///     let cond = |val: &u16| *val == HW_READY;
>> +///
>> +///     match read_poll_timeout(op, cond, Delta::from_millis(50), Some(Delta::from_secs(3))) {
> 
> Is there a reason for not writing the closures directly inline? I.e.
> 
>   match read_poll_timeout(
>       // The `op` closure reads the value of a specific status register.
>       || io.try_read16(0x1000),
>       // The `cond` closure takes a reference to the value returned by `op`
>       // and checks whether the hardware is ready.
>       |val| *val == HW_READY,
>       Delta::from_millis(50),
>       Some(Delta::from_secs(3))
>   )
> 
> I think it is closer to how people will actually use this function, and
> the expected types for the closures are available right in the function
> definition if they need more details.

Either is fine by me. I thought that not writing directly is more
readable.

Anyone else have an opinion?