[PATCH 9/9] rust: time: add ktime_get_real_seconds
COLD27d
From: Mike Lothian <hidden>
Date: 2026-08-26 16:29:25
Also in:
lkml
Subsystem:
delay, sleep, timekeeping, timers [rust], rust, the rest · Maintainers:
Andreas Hindborg, Miguel Ojeda, Linus Torvalds
Reading an `Instant<RealTime>` is the wrong tool for a caller that only wants a calendar time in seconds: it takes a full nanosecond timestamp and then needs a 64-bit division to get back to what the timekeeping core already maintains as a plain seconds field. Wrap `ktime_get_real_seconds()`, which is that field. Document the property that matters at the call site and that the type cannot express: the value follows CLOCK_REALTIME, so it is not monotonic and can move in either direction. Assisted-by: Claude:claude-opus-5 Signed-off-by: Mike Lothian <redacted> --- rust/kernel/time.rs | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/rust/kernel/time.rs b/rust/kernel/time.rs
index 363e93cbb139..a9922f1b493d 100644
--- a/rust/kernel/time.rs
+++ b/rust/kernel/time.rs@@ -129,6 +129,20 @@ fn ktime_get() -> bindings::ktime_t { } } +/// Returns the coarse wall-clock time in whole seconds since the Unix epoch. +/// +/// This is the cheap counterpart to reading an [`Instant<RealTime>`]: it reads the seconds field +/// the timekeeping core maintains, with no 64-bit division, and is what a caller that only needs a +/// calendar time should use. +/// +/// The value follows CLOCK_REALTIME, so it is not monotonic: settimeofday(2), NTP steps and leap +/// second handling can move it in either direction. +pub fn ktime_get_real_seconds() -> i64 { + // SAFETY: reading the timekeeping core's seconds field has no preconditions and is safe from + // any context. + unsafe { bindings::ktime_get_real_seconds() } +} + /// A monotonic that ticks while system is suspended. /// /// A nonsettable system-wide clock that is identical to CLOCK_MONOTONIC,