linux-kernel - Re: [PATCH net-next v2 2/6] rust: time: Introduce Delta type

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: <20241012195652.4d426c90@eugeo>
Date: Sat, 12 Oct 2024 19:56:52 +0100
From: Gary Guo <gary@...yguo.net>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: andrew@...n.ch, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
 hkallweit1@...il.com, tmgross@...ch.edu, ojeda@...nel.org,
 alex.gaynor@...il.com, 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,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/6] rust: time: Introduce Delta type

On Wed, 09 Oct 2024 23:00:15 +0900 (JST)
FUJITA Tomonori <fujita.tomonori@...il.com> wrote:

> On Mon, 7 Oct 2024 15:33:13 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
> >> I thought that from_secs(u16) gives long enough duration but
> >> how about the following APIs?
> >> 
> >> pub fn from_nanos(nanos: u64)
> >> pub fn from_micros(micros: u32)
> >> pub fn from_millis(millis: u16) 
> >> 
> >> You can create the maximum via from_nanos. from_micros and from_millis
> >> don't cause wrapping.  
> > 
> > When i talked about transitive types, i was meaning that to_nanos(),
> > to_micros(), to_millis() should have the same type as from_nanos(),
> > to_micros(), and to_millis().
> > 
> > It is clear these APIs cause discard. millis is a lot less accurate
> > than nanos. Which is fine, the names make that obvious. But what about
> > the range? Are there values i can create using from_nanos() which i
> > cannot then use to_millis() on because it overflows the u16? And i
> > guess the overflow point is different to to_micros()? This API feels
> > inconsistent to me. This is why i suggested u64 is used
> > everywhere. And we avoid the range issues, by artificially clamping to
> > something which can be represented in all forms, so we have a uniform
> > behaviour.  
> 
> I'll use u64 for all in v3; The range is to u64::MAX in nanoseconds
> for all the from_* functions.

If you do, I'd recommend to call it `Duration` rather than `Delta`.
`Delta` sounds to me that it can represent a negative delta, where
`Duration` makes sense to be non-negative.

And it also makes sense that `kernel::time::Duration` is the replacement
of `core::time::Duration`.

Thanks,
Gary