[RTEMS Project] #4691: Add support for FACE Technical Standard Restriction on POSIX Absolute Timers
trac at rtems.org
Mon Aug 1 15:13:59 UTC 2022
#4691: Add support for FACE Technical Standard Restriction on POSIX Absolute
Reporter: Joel Sherrill | Owner: Joel Sherrill
Type: enhancement | Status: assigned
Priority: normal | Milestone: 6.1
Component: posix | Version: 6
Severity: normal | Keywords:
Blocked By: | Blocking:
Most of the time, the FACE Technical Standard (https://opengroup.org/face)
defines a subset (e.g. profile) of a standard. It currently includes four
profiles of the POSIX 1003.1-2008 standard with a few optional features
like multiple processes and IPV6. However, in one case, it defines an
error case for something POSIX defines as required behavior. This ticket
is intended to track adding support for an application being able to
configure whether it wants the POSIX behavior or that defined by the FACE
== FACE Technical Standard Requirements
POSIX allows for setting a timer on CLOCK_REALTIME while the FACE
Technical Standard defines this as an error. This behavior and deviation
from POSIX has been in the FACE Technical Standard since the beginning and
was present in Edition 1.0. This is the language from Edition 1.0 of
the FACE Technical Standard which was written in the tone of a white paper
rather than as a set of requirements:
> 3.9.4 Time Management
> Partial support for the POSIX CLOCK_REALTIME, which permits a calendar-
based clock time to be set that becomes available to all partitions. Due
to safety and security-related considerations in the POSIX definitions of
this clock’s behavior, the configuration data will specify which
partitions (preferably one partition) have permissions to set (using the
clock_settime API) this clock. All partitions may have access to read this
clock, but an error will be returned for any partition that attempts to
set an alarm based on this clock that is based on absolute time (setting
of an alarm based on a relative time is supported). Partitions authorized
to set the calendar time will also be authorized to set the time zone
value that is visible to all other partitions.
Subsequent editions of the FACE Technical Standard have fine-tuned the
language and made requirements clearer with simpler direct "shall"
Also, although the term OSS UoC was defined in Edition 1.0, the
requirements now use this acronym for Operating System Segment Unit of
Conformance to refer to the operating system and foundational services.
Other types of segments are defined for applications, communications, and
device management. In Edition 3.1, the language has the same intent as
Edition 1.0 but the requirements are stated in a more direct and clearer
> 18.104.22.168 OSS POSIX Clock Requirements
> An OSS UoC provides support for POSIX clocks.
> 1. An OSS UoC shall support the POSIX Monotonic Clock option
(CLOCK_MONOTONIC), including setting absolute and relative timers on this
> 2. An OSS UoC shall support clock read-access based POSIX
CLOCK_REALTIME clock (calendar-based clock time).
> 3. An OSS UoC shall support setting a relative timer-based POSIX
CLOCK_REALTIME clock (calendar-based clock time).
> 4. An OSS UoC shall support clock time write access for POSIX
CLOCK_REALTIME clock value under the constraint that configuration data
specifies the partition is authorized to set the clock time (using the
> Note: The time value set by one partition becomes visible to all other
partitions. The timezone value set by one POSIX process using the tzset()
or setenv() APIs is local to that POSIX process.
> 5. An OSS UoC shall return an error when a software component
attempts to set an absolute timer on the POSIX CLOCK_REALTIME clock.
> Note: The behavior is necessary (e.g., to prevent backwards and forwards
shifts in sequential timers) due to the setting of POSIX_CLOCK_REALTIME
clock impacting all partitions.
The use of the word "partition" is intentional because the FACE Technical
Standard includes ARINC 653 and POSIX standards. ARINC 653 defines a time
and space partitioned real-time environment. POSIX or ARINC 653
applications can be hosted in a partition. In three of the four profiles,
ARINC 653 is required while in the fourth it is optional. RTEMS can be
hosted in an ARINC 653 partition using a paravirtualized configuration
with a BSP that adapts it to the environment.
The requirement being addressed by this ticket is (5) since RTEMS
currently meets the other requirements. (5) contradicts the POSIX standard
and modifying RTEMS to not support absolute POSIX timers is not an
== Proposed Solution
The proposed solution is to add a confdefs.h configure option that enables
this behavior when the OSS UoC (e.g. operating system) must provide FACE
conformant behavior. When not defined, the POSIX behavior will be in
This will require additions to the confdefs.h family of headers, adding a
test, and updating documentation.
 POSIX timer_create -
 FACE Technical Standard, Edition 1.0. January 2012.
 FACE Technical Standard, Edition 3.1. July 2020.
Ticket URL: <http://devel.rtems.org/ticket/4691>
RTEMS Project <http://www.rtems.org/>
More information about the bugs