[PATCH 9/9] rust: time: add ktime_get_real_seconds

From: Mike Lothian

Date: Wed Aug 26 2026 - 12:29:44 EST


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 <mike@xxxxxxxxxxxxxx>
---
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,