[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=oPCO=+yksn4qKemp+OkCm-+T54DQz9f3sSD5SQQLRMQ@mail.gmail.com>
Date: Wed, 22 Feb 2023 13:28:53 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Asahi Lina <lina@...hilina.net>, Boqun Feng <boqun.feng@...il.com>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
John Stultz <jstultz@...gle.com>,
Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org, asahi@...ts.linux.dev,
Heghedus Razvan <heghedus.razvan@...tonmail.com>
Subject: Re: [PATCH] rust: time: New module for timekeeping functions
On Wed, Feb 22, 2023 at 1:24 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Back to time deltas (or duration types). Independent of the above it
> might make sense to be type strict about these as well. Especially if we
> go one step further and have timers based on CLOCK_* which need to be
> armed by either timestamps for absolute expiry or time deltas for
> relative to now expiry. I definitely can see a point for requiring
> matching time delta types there.
Yeah, if you think having several delta types would make sense for
some use case, or at least prevent some bugs statically (especially if
you have been similar issues in the past), then I think we should
eventually do it. Not necessarily now, of course. We should just keep
it in mind before the types get a lot of use, because it can be easier
to merge types (if they end up being unneeded) than to split them
later (double-checking each instance).
Thanks for all your feedback on this!
Cheers,
Miguel
Powered by blists - more mailing lists