linux-kernel - Re: [PATCH] rust: time: New module for timekeeping functions

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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