POSIX Base Standards Revision Contents Proposal Austin-1 Page 1 of 3 Submitted by Don Cragun, Sun Microsystems, Inc. August 31, 1998 The resolution from the July 1998 PASC SEC meeting forming the revision study group was: PASC Resolution 9807-04 PASC SEC authorizes a Study Group with open membership to initiate a joint revision of ISO/IEC 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the appropriate parts of The Open Group Single UNIX Specification. This revision should result in a common standard or standards, which must be completed within the next three (3) to five (5) years. (Note: See IEEE/PASC Resolution 9801-03 for additional applicable information about possible amendments.) Chair will be Andrew Josey. When we look at this resolution, one question is: What are the "appropriate parts" of SUSv2? If we look at POSIX.1, POSIX.2, and SUSv2 we all know that SUSv2 is a superset of the normative parts of POSIX. In some cases, entire books are extensions to POSIX; in other cases the breakdown is much more complex. It goes something like this: XBD5: There is no POSIX book corresponding to this book. It contains major chunks of POSIX.1 Section 2 (Terminology and General Requirements), POSIX.2 Section 2 (Terminology and General Requirements), and extended definitions common to XCurses4v2, XCU5, and XSH5. XCU5: This book is similar to POSIX.2 combined with POSIX.2a. It contains all of POSIX.2 and POSIX.2a except: -1. major chunks of Section 2 (Terminology and General Requirements) [which are included in XBD5], -2. Section 7 (Language Independent System Services) and Annex B (C-Language Bindings Option) [which are included in XSH5], -3. Annex E (Rationale and Notes) [although some of of this is included in Application Usage and Examples sections], -4. Annex F (Portability Considerations), -5. Annex G (Sample National Profile), and -6. Annex H (Proposals for Future Revisions). It also contains: +1. POSIX.1 Section 10 (Data Interchange Format) cpio and tar archive format header block descriptions associated with the cpio, pax, and tar utilities, +2. full alignment with ISO C (including Amendment 1), and +3. several extensions (additional utilities and additional options to POSIX utilities). XCU5 does not contain IEEE Std 1003.2d-1994 (Batch Extensions). XSH5: This book (2 volumes) is similar to POSIX.1-1996. It contains all of POSIX.1-1996 except: -1. major chunks of Section 2 (Terminology and General Requirements) [which are included in XBD5], -2. Section 10 (Data Interchange Format) archive format header block descriptions associated with the cpio, pax, and tar utilities [which are included in XCU5], -3. Annex B (Rationale and Notes) [although some of this is included in Examples and Application Usage sections], -4. Annex D (Profiles), -5. Annex E (Sample National Profile), POSIX Base Standards Revision Contents Proposal Austin-1 Page 2 of 3 -6. Annex F (Portability Considerations), -7. Annex G (Performance Metrics), and -8. Annex H (Realtime Files). However, XSH5 mandates one choice in several cases where POSIX.1 allows two choices (alignment with FIPS 151-2) and XSH5 requires C Standard Language-Dependent System Support. If also contains: +1. POSIX.2 Section 7 (Language Independent System Services) and Annex B (C-Language Bindings Option), +2. full alignment with ISO C (including Amendment 1 [MSE]), and +3. lots of extensions (additional functions and additional options to POSIX functions). XSH5 lumps several POSIX options into larger "Feature Groups". Note that XCU5 items -2 and +1 and XSH5 items -2, +1, +2 [except for the MSE], and symbolic links (out of +3) are all covered by P1003.1a and P1003.2b. XNS5: Not specified by any approved POSIX standard. Most of P1003.1g's current draft is already specified by XNS5. XNS5 contains lots of extensions to P1003.1g. XCurses4v2: Not specified by any POSIX standard or PASC Project. Sun proposes that the next SUS, the replacements for IEEE Stds 1003.1 and 1003.2, and the replacements for ISO/IEC ISs 9945-1 and 9945-2 (hereafter referred to as next common standard) have the following characteristics: 1. XCurses will not be part of the next common standard agreed to by TOG, PASC, and WG15; it will remain a separate book maintained by TOG. {1} 2. If and only if P1003.1g is approved by 12/31/1999 as an IEEE Standard, then the next version (or issue) of XNS will be part of the next common standard. {2} 3. XBD5, XCU5, and XSH5 {3} will be the basis for the text of the next common standard. 4. All extensions to POSIX in XBD5, XCU5, and XSH5 {3} will appear in the next common standard. 5. All of the grandfathered projects (P1003.1a, P1003.2b, P1003.1d (Additional Realtime Extensions), P1003.1g (Protocol Independent Interfaces), P1003.1h (SRASS), P1003.1j (Advanced Realtime Extensions), P1003.1m (Checkpoint/Restart), and P1003.1q (Trace)) will be merged into the next common standard if and only if they are approved as IEEE Standards by 12/31/1999. {2} ___________________ Footnotes: {1} This does not mean that XCurses will no longer be part of the SUS; only that curses won't be specified by IEEE or ISO standards. {2} This corresponds to the PASC SEC resolution allowing these projects to be implemented as amendments for POSIX.1 and POSIX.2 if and only if they are approved as IEEE Standards by 12/31/1999. {3} Add XNS5 to this list if P1003.1g becomes a standard by 12/31/1999. POSIX Base Standards Revision Contents Proposal Austin-1 Page 3 of 3 6. We add all of the rationale and notes from POSIX.1 and POSIX.2 into the next common standard. {4} 7. We don't care whether these are published as a three logical volume set (e.g. XBD, XCU, XSH), a four logical volume set (e.g. XBD, XCU, XSH, Xrationale), or a single volume (e.g. Xcommon), but we think the first two choices would be better than a single volume or the current POSIX two volume version. {5} 8. If the PASC SSWG provides input on how POSIX.1 should be modified such that IEEE Std 1003.13 would not have needed to slice-and-dice POSIX.1, the next common standard should use that input to make appropriate changes. {6} ___________________ Footnotes: {4} At a recent PASC SEC meeting Jason argued that POSIX and SUS serve different audiences; POSIX serves system implementors, SUS serves application writers. We believe that the reason POSIX provides more information to system implementors is the lack of the rationale in SUS. When we go to the next common standard, we don't want to lose this valuable information (even though we will have to sift through a lot of cruft). {5} Note that a POSIX equivalent of XBD didn't make sense with the old method of updating POSIX.1 and POSIX.2 standards because they were independent. XBD makes sense in the TOG and new models because POSIX.1 (XSH) and POSIX.2 (XCU) will always be revised at the same time (i.e. updates to POSIX.1 or POSIX.2 won't break definitions shared by both). {6} When P1003.13 was approved they were granted a license to slice and dice POSIX.1 if they then modified POSIX.1 such that slice and dice would no longer be needed. We now have IEEE Std 1003.13, but the second part hasn't been completed yet.