349 lines
15 KiB
HTML
349 lines
15 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>Rationale</title>
|
|
</head>
|
|
<body>
|
|
|
|
<basefont size="3">
|
|
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group</font></center>
|
|
|
|
<hr size="2" noshade>
|
|
<h3><a name="tag_01_02"></a>Conformance</h3>
|
|
|
|
<p>The terms "profile" and "profiling" are used throughout this section.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>These conformance definitions are descended from those in the ISO POSIX-1:1996 standard, but with changes for the
|
|
following:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>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).</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The addition of a definition of subprofiling considerations, to allow smaller profiles of options.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Options from the ISO POSIX-2:1993 standard are also now included, as IEEE Std 1003.1-2001 merges the
|
|
functionality from it.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h4><a name="tag_01_02_01"></a>Implementation Conformance</h4>
|
|
|
|
<p>These definitions allow application developers to know what to depend on in an implementation.</p>
|
|
|
|
<p>There is no definition of a "strictly conforming implementation''; that would be an implementation that provides <i>only</i>
|
|
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.</p>
|
|
|
|
<h5><a name="tag_01_02_01_01"></a>Requirements</h5>
|
|
|
|
<p>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 <i>Strictly Conforming POSIX.1 Application</i>, to
|
|
be a <i>conforming implementation</i>.</p>
|
|
|
|
<h5><a name="tag_01_02_01_02"></a>Documentation</h5>
|
|
|
|
<p>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 <a href="../basedefs/limits.h.html"><i><limits.h></i></a> and <a
|
|
href="../basedefs/unistd.h.html"><i><unistd.h></i></a>.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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).</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="tag_01_02_01_03"></a>POSIX Conformance</h5>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>_POSIX_JOB_CONTROL</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>_POSIX_SAVED_IDS</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>_POSIX_VDISABLE</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="tag_01_02_01_04"></a>XSI Conformance</h5>
|
|
|
|
<p>This section is added since the revision merges in the base volumes of the Single UNIX Specification.</p>
|
|
|
|
<p>XSI conformance can be thought of as a profile, selecting certain options from IEEE Std 1003.1-2001.</p>
|
|
|
|
<h5><a name="tag_01_02_01_05"></a>Option Groups</h5>
|
|
|
|
<p>The concept of "Option Groupsc" 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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="tag_01_02_01_06"></a>Subprofiling Considerations</h5>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The following summarizes the rules for the limit types:</p>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="3" align="center">
|
|
<tr valign="top">
|
|
<th align="center">
|
|
<p class="tent"><b>Limit</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Fixed</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Minimum Acceptable</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Maximum Acceptable</b></p>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<th align="center">
|
|
<p class="tent"><b>Type</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Value</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Value</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Value</b></p>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent">Standard</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"><i>Xs</i></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"><i>Ys</i></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"><i>Zs</i></p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent">Profile</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"><i>Xp</i> == <i>Xs</i></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"><i>Yp</i> >= <i>Ys</i></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"><i>Zp</i> <= <i>Zs</i></p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"> </p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">(No change)</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">(May increase the limit)</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">(May decrease the limit)</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</center>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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).</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>An example which has previously allowed implementations to support both the base standard and two other profiles in a compatible
|
|
manner follows:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<tt>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)
|
|
</tt>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>Another example:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<tt>Base standard (POSIX.1-1996): _POSIX_NGROUPS_MAX 0
|
|
Base standard: NGROUPS_MAX minimum maximum _POSIX_NGROUP_MAX
|
|
FIPS profile/SUSv2 NGROUPS_MAX 8
|
|
</tt>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>A profile may lower a minimum maximum below the equivalent _POSIX value:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<tt>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)
|
|
</tt>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="tag_01_02_01_07"></a>Options</h5>
|
|
|
|
<p>The final subsections within <i>Implementation Conformance</i> 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.</p>
|
|
|
|
<h4><a name="tag_01_02_02"></a>Application Conformance</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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</p>
|
|
|
|
<h5><a name="tag_01_02_02_01"></a>Strictly Conforming POSIX Application</h5>
|
|
|
|
<p>This definition is analogous to that of an ISO C standard "conforming program".</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="tag_01_02_02_02"></a>Conforming POSIX Application</h5>
|
|
|
|
<p>Examples of <National Bodies> include ANSI, BSI, and AFNOR.</p>
|
|
|
|
<h5><a name="tag_01_02_02_03"></a>Conforming POSIX Application Using Extensions</h5>
|
|
|
|
<p>Due to possible requirements for configuration or implementation characteristics in excess of the specifications in <a href=
|
|
"../basedefs/limits.h.html"><i><limits.h></i></a> 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.</p>
|
|
|
|
<h5><a name="tag_01_02_02_04"></a>Strictly Conforming XSI Application</h5>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="tag_01_02_02_05"></a>Conforming XSI Application Using Extensions</h5>
|
|
|
|
<p>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.</p>
|
|
|
|
<h4><a name="tag_01_02_03"></a>Language-Dependent Services for the C Programming Language</h4>
|
|
|
|
<p>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 <i>de facto</i> primary language on POSIX and the UNIX system makes this a
|
|
necessary and workable situation.</p>
|
|
|
|
<h4><a name="tag_01_02_04"></a>Other Language-Related Specifications</h4>
|
|
|
|
<p>There is no additional rationale provided for this section.</p>
|
|
|
|
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|