[RTEMS Project] #4691: Add support for FACE Technical Standard Restriction on POSIX Absolute Timers

[RTEMS trac]

#4691: Add support for FACE Technical Standard Restriction on POSIX Absolute
Timers
----------------------------+---------------------------
  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:
----------------------------+---------------------------
 = Overview

 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
 Technical Standard.

 == FACE Technical Standard Requirements

 POSIX allows for setting a timer on CLOCK_REALTIME[1] 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[2]. 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"
 statements.

 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[3], the language has the same intent as
 Edition 1.0 but the requirements are stated in a more direct and clearer
 manner.

 > 4.1.1.3       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
 clock.
 > 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
 clock_settime() API).
 > 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
 acceptable option.

 == 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
 effect.

 This will require additions to the confdefs.h family of headers, adding a
 test, and updating documentation.

 == References

 [1] POSIX timer_create -
 https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html

 [2] FACE Technical Standard, Edition 1.0. January 2012.
 https://publications.opengroup.org/c122.

 [3] FACE Technical Standard, Edition 3.1. July 2020.
 https://publications.opengroup.org/c207.

--
Ticket URL: <http://devel.rtems.org/ticket/4691>
RTEMS Project <http://www.rtems.org/>
RTEMS Project