The terms "profile" and "profiling" are used throughout this section.
A profile of a standard or standards is a codified set of option selections, such that by being conformant to a profile, particular classes of users are specifically supported.
These definitions allow application developers to know what to depend on in an implementation.
There is no definition of a "strictly conforming implementation''; that would be an implementation that provides only those facilities specified by POSIX.1 with no extensions whatsoever. This is because no actual operating system implementation can exist without system administration and initialization facilities that are beyond the scope of POSIX.1.
The word "support" is used in certain instances, rather than "provide", in order to allow an implementation that has no resident software development facilities, but that supports the execution of a Strictly Conforming POSIX.1 Application, to be a conforming implementation.
The conformance documentation is required to use the same numbering scheme as POSIX.1 for purposes of cross-referencing. All options that an implementation chooses are reflected in <limits.h> and <unistd.h>.
Note that the use of "may" in terms of where conformance documents record where implementations may vary, implies that it is not required to describe those features identified as undefined or unspecified.
Other aspects of systems must be evaluated by purchasers for suitability. Many systems incorporate buffering facilities, maintaining updated data in volatile storage and transferring such updates to non-volatile storage asynchronously. Various exception conditions, such as a power failure or a system crash, can cause this data to be lost. The data may be associated with a file that is still open, with one that has been closed, with a directory, or with any other internal system data structures associated with permanent storage. This data can be lost, in whole or part, so that only careful inspection of file contents could determine that an update did not occur.
Also, interrelated file activities, where multiple files and/or directories are updated, or where space is allocated or released in the file system structures, can leave inconsistencies in the relationship between data in the various files and directories, or in the file system itself. Such inconsistencies can break applications that expect updates to occur in a specific sequence, so that updates in one place correspond with related updates in another place.
For example, if a user creates a file, places information in the file, and then records this action in another file, a system or power failure at this point followed by restart may result in a state in which the record of the action is permanently recorded, but the file created (or some of its information) has been lost. The consequences of this to the user may be undesirable. For a user on such a system, the only safe action may be to require the system administrator to have a policy that requires, after any system or power failure, that the entire file system must be restored from the most recent backup copy (causing all intervening work to be lost).
The characteristics of each implementation will vary in this respect and may or may not meet the requirements of a given application or user. Enforcement of such requirements is beyond the scope of POSIX.1. It is up to the purchaser to determine what facilities are provided in an implementation that affect the exposure to possible data or sequence loss, and also what underlying implementation techniques and/or facilities are provided that reduce or limit such loss or its consequences.
This really means conformance to the base standard; however, since this document includes the core material of the Single UNIX Specification, the standard developers decided that it was appropriate to segment the conformance requirements into two, the former for the base standard, and the latter for the Single UNIX Specification (denoted XSI Conformance).
Within POSIX.1 there are some symbolic constants that, if defined to a certain value or range of values, indicate that a certain option is enabled. Other symbolic constants exist in POSIX.1 for other reasons.
In this version, some features that were previously optional have been made mandatory. For backwards compatibility, the symbolic constants associated with the option are still required now with fixed allowable ranges or values. The following options from the previous version of this standard are now mandatory:
_POSIX_ASYNCHRONOUS_IO _POSIX_BARRIERS _POSIX_CLOCK_SELECTION _POSIX_MAPPED_FILES _POSIX_MEMORY_PROTECTION _POSIX_READER_WRITER_LOCKS _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SPIN_LOCKS _POSIX_THREAD_SAFE_FUNCTIONS _POSIX_THREADS _POSIX_TIMEOUTS _POSIX_TIMERS
A POSIX-conformant system may support the XSI option required by the Single UNIX Specification. This was intentional since the standard developers intend them to be upwards-compatible, so that a system conforming to the Single UNIX Specification can also conform to the base standard at the same time.
This section is included to describe the conformance requirements for the base volumes of the Single UNIX Specification.
XSI conformance can be thought of as a profile, selecting certain options from POSIX.1-2008.
The concept of "Option Groups" is included to allow collections of related functions or options to be grouped together. This has been used as follows: the "XSI Option Groups" have been created to allow super-options, collections of underlying options and related functions, to be collectively supported by XSI-conforming systems.
The standard developers considered the matter of subprofiling and decided it was better to include an enabling mechanism rather than detailed normative requirements. A set of subprofiling options was developed and included later in this volume of POSIX.1-2008 as an informative illustration.
The goal of not simultaneously fixing maximums and minimums was to allow implementations of the base standard or standards to
support multiple profiles without conflict.
The following summarizes the rules for the limit types:
|
Limit Type |
Fixed Value |
Minimum Acceptable Value |
Maximum Acceptable Value |
|---|---|---|---|
|
Standard Profile |
Xs |
Ys |
Zs |
The intent is that ranges specified by limits in profiles be entirely contained within the corresponding ranges of the base standard or standards being profiled, and that the unlimited end of a range in a base standard must remain unlimited in any profile of that standard.
Thus, the fixed _POSIX_* limits are constants and must not be changed by a profile. The variable counterparts (typically without the leading _POSIX_) can be changed but still remain semantically the same; that is, they still allow implementation values to vary as long as they meet the requirements for that value (be it a minimum or maximum).
Where a profile does not provide a feature upon which a limit is based, the limit is not relevant. Applications written to that profile should be written to operate independently of the value of the limit.
An example which has previously allowed implementations to support both the base standard and two other profiles in a compatible manner follows:
Base standard (POSIX.1-1996): _POSIX_CHILD_MAX 6
Base standard: CHILD_MAX minimum maximum _POSIX_CHILD_MAX
FIPS profile/SUSv2 CHILD_MAX 25 (minimum maximum)
Another example:
Base standard (POSIX.1-1996): _POSIX_NGROUPS_MAX 0
Base standard: NGROUPS_MAX minimum maximum _POSIX_NGROUP_MAX
FIPS profile/SUSv2 NGROUPS_MAX 8
A profile may lower a minimum maximum below the equivalent _POSIX value:
Base standard: _POSIX_foo_MAX Z
Base standard: foo_MAX _POSIX_foo_MAX
profile standard : foo_MAX X (X can be less than, equal to,
or greater than _POSIX_foo_MAX)
In this case an implementation conforming to the profile may not conform to the base standard, but an implementation to the base standard will conform to the profile.
The final subsections within Implementation Conformance list the core options within POSIX.1-2008. This includes both options for the System Interfaces volume of POSIX.1-2008 and the Shell and Utilities volume of POSIX.1-2008.
These definitions guide users or adapters of applications in determining on which implementations an application will run and how much adaptation would be required to make it run on others. These definitions are modeled after related ones in the ISO C standard.
POSIX.1 occasionally uses the expressions "portable application" or "conforming application". As they are used, these are synonyms for any of these terms. The differences between the classes of application conformance relate to the requirements for other standards, the options supported (such as the XSI option) or, in the case of the Conforming POSIX.1 Application Using Extensions, to implementation extensions. When one of the less explicit expressions is used, it should be apparent from the context of the discussion which of the more explicit names is appropriate
This definition is analogous to that of an ISO C standard "conforming program".
The major difference between a Strictly Conforming POSIX Application and an ISO C standard strictly conforming program is that the latter is not allowed to use features of POSIX that are not in the ISO C standard.
Examples of <National Bodies> include ANSI, BSI, and AFNOR.
Due to possible requirements for configuration or implementation characteristics in excess of the specifications in <limits.h> or related to the hardware (such as array size or file space), not every Conforming POSIX Application Using Extensions will run on every conforming implementation.
This is intended to be upwards-compatible with the definition of a Strictly Conforming POSIX Application, with the addition of the facilities and functionality included in the XSI option.
Such applications may use extensions beyond the facilities defined by POSIX.1-2008 including the XSI option, but need to document the additional requirements.
POSIX.1 is, for historical reasons, both a specification of an operating system interface, shell and utilities, and a C binding for that specification. Efforts had been previously undertaken to generate a language-independent specification; however, that had failed, and the fact that the ISO C standard is the de facto primary language on POSIX and the UNIX system makes this a necessary and workable situation.
There is no additional rationale provided for this section.
return to top of page