id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,blockedby,blocking 4691,Add support for FACE Technical Standard Restriction on POSIX Absolute Timers,Joel Sherrill,Joel Sherrill,"= 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. ",enhancement,closed,normal,6.1,posix,6,normal,fixed,qualification,,,