[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZxAcJEDFQ-n64mnd@Boquns-Mac-mini.local>
Date: Wed, 16 Oct 2024 13:03:48 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, andrew@...n.ch,
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, anna-maria@...utronix.de, frederic@...nel.org,
tglx@...utronix.de, arnd@...db.de, jstultz@...gle.com,
sboyd@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 3/8] rust: time: Change output of Ktime's sub
operation to Delta
On Wed, Oct 16, 2024 at 12:52:08PM +0900, FUJITA Tomonori wrote:
> Change the output type of Ktime's subtraction operation from Ktime to
> Delta. Currently, the output is Ktime:
>
> Ktime = Ktime - Ktime
>
> It means that Ktime is used to represent timedelta. Delta is
> introduced so use it. A typical example is calculating the elapsed
> time:
>
> Delta = current Ktime - past Ktime;
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@...il.com>
> ---
> rust/kernel/time.rs | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/rust/kernel/time.rs b/rust/kernel/time.rs
> index 38a70dc98083..8c00854db58c 100644
> --- a/rust/kernel/time.rs
> +++ b/rust/kernel/time.rs
> @@ -74,16 +74,16 @@ pub fn to_ms(self) -> i64 {
> /// Returns the number of milliseconds between two ktimes.
> #[inline]
> pub fn ktime_ms_delta(later: Ktime, earlier: Ktime) -> i64 {
> - (later - earlier).to_ms()
> + (later - earlier).as_millis()
> }
>
> impl core::ops::Sub for Ktime {
> - type Output = Ktime;
> + type Output = Delta;
>
> #[inline]
> - fn sub(self, other: Ktime) -> Ktime {
> - Self {
> - inner: self.inner - other.inner,
> + fn sub(self, other: Ktime) -> Delta {
> + Delta {
> + nanos: self.inner - other.inner,
My understanding is that ktime_t, when used as a timestamp, can only
have a value in range [0, i64::MAX], so this substraction here never
overflows, maybe we want add a comment here?
We should really differ two cases: 1) user inputs may cause overflow vs
2) implementation errors or unexpected hardware errors cause overflow, I
think.
Regards,
Boqun
> }
> }
> }
> --
> 2.43.0
>
>
Powered by blists - more mailing lists