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

[Gary Guo]

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

> On Mon, 7 Oct 2024 15:33:13 +0200
> Andrew Lunn <andrew@xxxxxxx> 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