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 conformance definitions are descended from those in the ISO POSIX-1:1996 standard, but with changes for the following:
The addition of profiling options, allowing larger profiles of options such as the XSI extension used by the Single UNIX Specification. In effect, it has profiled itself (that is, created a self-profile).
The addition of a definition of subprofiling considerations, to allow smaller profiles of options.
The addition of a hierarchy of super-options for XSI; these were formerly known as "Feature Groups" in the System Interfaces and Headers, Issue 5 specification.
Options from the ISO POSIX-2:1993 standard are also now included, as IEEE Std 1003.1-2001 merges the functionality from it.
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 revision 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.
Within POSIX.1 there are some symbolic constants that, if defined, indicate that a certain option is enabled. Other symbolic constants exist in POSIX.1 for other reasons.
As part of the revision some alignment has occurred of the options with the FIPS 151-2 profile on the POSIX.1-1990 standard. The following options from the POSIX.1-1990 standard are now mandatory:
_POSIX_JOB_CONTROL
_POSIX_SAVED_IDS
_POSIX_VDISABLE
A POSIX-conformant system may support the XSI extensions of 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 added since the revision merges in the base volumes of the Single UNIX Specification.
XSI conformance can be thought of as a profile, selecting certain options from IEEE Std 1003.1-2001.
The concept of "Option Groups" is introduced to IEEE Std 1003.1-2001 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. These reflect the "Feature Groups" from the System Interfaces and Headers, Issue 5 specification.
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 IEEE Std 1003.1-2001 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 |
Fixed |
Minimum Acceptable |
Maximum Acceptable |
|---|---|---|---|
|
Type |
Value |
Value |
Value |
|
Standard |
Xs |
Ys |
Zs |
|
Profile |
Xp == Xs |
Yp >= Ys |
Zp <= Zs |
|
|
(No change) |
(May increase the limit) |
(May decrease the limit) |
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 IEEE Std 1003.1-2001. This includes both options for the System Interfaces volume of IEEE Std 1003.1-2001 and the Shell and Utilities volume of IEEE Std 1003.1-2001.
These definitions guide users or adaptors 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 extension) 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 extension.
Such applications may use extensions beyond the facilities defined by IEEE Std 1003.1-2001 including the XSI extension, 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.