CHERIoT-Platform/cheriot-rtos

`gettimeofday` support should be moved to an RTC compartment.

Open

#679 opened on Mar 18, 2026

View on GitHub
 (1 comment) (0 reactions) (0 assignees)C++ (66 forks)auto 404
good first issue

Repository metrics

Stars
 (163 stars)
PR merge metrics
 (PR metrics pending)

Description

Currently, we have gettimeofday in the network stack. It is in two parts:

  • The SNTP compartment, which updates the shared object with the current wall-clock time and the cycle time when it was updated.
  • The time library that wraps reading this and implements the gettimeofday function.

For the demo at embedded world, we added RTC support. This involved having an external RTC driver call into the SNTP compartment to tell it the current time.

This is weird layering.

We should retain the current library, but move it into the RTOS, and separate out the time-updating and SNTP querying parts of the current SNTP compartment. The time-updating part should live in the RTOS, the SNTP part should remain in the network stack and call into the time-updating API.

This is mostly just moving code around, but needs a few tweaks:

  • If gettimeofday is called without the time being set, it should call into the time-managing compartment
  • The time-managing compartment should own the platform RTC if one exists.
  • The time-managing component should set the RTC time from SNTP if provided with a time.

Contributor guide

Research direction
Study the current SNTP compartment and the time library to understand the existing layering. Then design the new compartment separation: a time managing compartment in the RTOS that owns the RTC and provides an API for setting/getting time, and a modified SNTP compartment that calls into this API. Look at the existing RTC driver integration and plan code movement.
Tech stack
c
Domain
embedded iotoperating systems
Issue type
Refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
CRTOS conceptsSNTPRTC
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40