Re: [PATCH v1 2/2] rust: Add read_poll_timeout_atomic function

From: Danilo Krummrich
Date: Tue Aug 26 2025 - 10:25:02 EST


On Thu Aug 21, 2025 at 5:57 AM CEST, FUJITA Tomonori wrote:
> +pub fn read_poll_timeout_atomic<Op, Cond, T>(
> + mut op: Op,
> + mut cond: Cond,
> + delay_delta: Delta,
> + timeout_delta: Delta,
> +) -> Result<T>
> +where
> + Op: FnMut() -> Result<T>,
> + Cond: FnMut(&T) -> bool,
> +{
> + let mut left_ns = timeout_delta.as_nanos();
> + let delay_ns = delay_delta.as_nanos();
> +
> + loop {
> + let val = op()?;
> + if cond(&val) {
> + // Unlike the C version, we immediately return.
> + // We know the condition is met so we don't need to check again.
> + return Ok(val);
> + }
> +
> + if left_ns < 0 {
> + // Unlike the C version, we immediately return.
> + // We have just called `op()` so we don't need to call it again.
> + return Err(ETIMEDOUT);
> + }
> +
> + if !delay_delta.is_zero() {
> + udelay(delay_delta);
> + left_ns -= delay_ns;
> + }
> +
> + cpu_relax();
> + left_ns -= 1;

How do we know that each iteration costs 1ns? To make it even more obvious, we
don't control the implementation of cond(). Shouldn't we use ktime for this?