[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72mX4nJNw2RbZd9U_FdbGmnNHav3wMPMJyLSRN=PULan8g@mail.gmail.com>
Date: Wed, 2 Oct 2024 14:35:57 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andrew Lunn <andrew@...n.ch>, Thomas Gleixner <tglx@...utronix.de>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, 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
Subject: Re: [PATCH net-next v1 1/2] rust: add delay abstraction
On Wed, Oct 2, 2024 at 2:19 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> How well know is that? And is there a rust-for-linux wide preference
> to use Duration for time? Are we going to get into a situation that
> some abstractions use Duration, others seconds, some milliseconds,
> etc, just like C code?
We have `Ktime` that wraps `ktime_t`.
However, note that something like `Ktime` or `Duration` are types, not
a typedef, i.e. it is not an integer where you may confuse the unit.
So, for instance, the implementation here calls `as_micros()` to get
the actual integer. And whoever constructs e.g. a `Duration` has
several constructors to do so, not just the one that takes seconds and
nanoseconds, e.g. there is also `from_millis()`.
Perhaps we may end up needing different abstractions depending on what
we need (Cc'ing Thomas), but we will almost certainly want to still
use types like this, rather than plain integers or typedefs where
units can be confused.
> Anyway, i would still document the parameter is a Duration, since it
> is different to how C fsleep() works.
That is in the signature itself -- so taking into account what I
mentioned above, does it make sense that seeing the type in the
signature would be enough?
Cheers,
Miguel
Powered by blists - more mailing lists