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

[Gaelan Steele <gbs@canishe.com>]

> On Feb 21, 2023, at 9:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Tue, Feb 21 2023 at 09:13, Josh Stone wrote:
> 
>> On 2/21/23 4:32 AM, Thomas Gleixner wrote:
>>> Now the problem is that 'Instant' in it's specification is bound to
>>> CLOCK_MONOTONIC and there is no way to express CLOCK_BOOTTIME, but
>>> that's a shortcoming of the spec which ignores CLOCK_BOOTTIME
>>> completely. IOW, that's also a problem for user space.
>> 
>> That's not exactly *specified* -- it's meant to be opaque time. It is
>> documented that this currently uses clock_gettime monotonic on unix
>> targets, but "Disclaimer: These system calls might change over time."
>> CLOCK_MONOTONIC isn't even consistent across unix targets whether that
>> counts suspended time. It's been debated if we should switch to
>> CLOCK_BOOTTIME on Linux, but for now we're sticking to monotonic:
> 
> You'll need both when you want to implement substantial parts of the low
> level user space stack in Rust. Same for CLOCK_TAI.
> 
> Thanks,
> 
>        tglx

std isn’t really designed to provide full coverage of any particular OS
interface - it has to provide concepts that map cleanly onto Windows and
every flavor of Unix.[1] Low-level Unix Rust code typically uses the libc
crate, which just exports everything from libc as an unsafe function, or
one of several safe wrappers (nix is the most popular one, I’m partial to
rustix), alongside std.

[1]: std does in cases provide OS-specific functions - for example,
std::fs::Metadata (~= struct stat) has Unix-specific ways to get the
mode - but again, the goal here is to be broadly useful, not full
coverage.

Best wishes,
Gaelan