POSIX Update

Our Standards Report Editor, Nick Stoughton, welcomes dialogue between this column and you, the readers. Please send your comments to <nick@usenix.org>.

Those of you who have been following this column over recent months will know about the work of the "Austin Group," a collaboration among the IEEE Portable Application Standards Committee (PASC), The Open Group (TOG), and ISO JTC1/SC22/WG15 to produce a revision of the two core POSIX standards: POSIX.1 and POSIX.2. The result will be a single standard, in four volumes, replacing the old POSIX.1, POSIX.2, and the majority of the Single UNIX Specification (SUS) from TOG.

On June 1, two important events occurred. The first was that the relevant authorities in the IEEE Standards Department and at TOG were able to sign a Joint "Memorandum of Understanding" on the development and publication of this new work. ISO will also become a signatory to this understanding at a future date. However, since the majority of this document deals with intellectual property, and all the intellectual property rights in the base documents belongs to either the IEEE or TOG at present, the lack of an ISO signature should not be taken as an ominous sign, at least not yet!

The second June 1 event was the publication of draft 1 of the new document. At present, only three of the four volumes have been started: Base Definitions (known as XBD), System Interfaces and Headers (XSH), and Commands and Utilities (XCU). The fourth, Rationale (XRAT), is trailing behind since this is a guide, containing no normative requirements, and requires a far higher degree of effort to produce than the base documents. XRAT notwithstanding, draft 1 occupies exactly 2,500 pages. And this is before we have added any of the new material! Reviewing this will occupy much of the time before the next face-to-face meeting of the group, in July in Montreal.

Draft 1 concentrates on taking the existing SUS and presenting it in a new language, with different options from its previous edition. Any interfaces that were marked as legacy or obsolete in the previous editions of SUS or POSIX have been removed. Interfaces that now have better, more consistent, alternatives become "new obsolete"; application developers are being steered away from using these interfaces in favor of the better alternative. Of course, removing an interface from the standard does not remove it from a vendor's implementation; it merely removes the requirement for that vendor to support that interface.

The second draft, due out later this year, should have considerably more functionality from other amendments that are expected to finish before then (e.g., POSIX.1g, Protocol Independent Interfaces, or sockets).

The new draft looks a lot more like the SUS than POSIX.1 or POSIX.2. This is really just a style issue. Rather than grouping interfaces by functional area, as in POSIX at present, all the interfaces are described in alphabetical order. It is felt that this makes it more useful for the application developer rather than the system implementor. Of course, the cynical will feel that this is just TOG taking over and replacing POSIX with its own material, but I would beg patience. Several things have been changed to make the language more precise (e.g., the use of ISO terms such as "shall" rather than the old TOG style of "will") while trying to retain some of the clarity and brevity used in the SUS. For example, there is considerable use of shading to show optional behavior, which most people believe shows the intent far more clearly than trying to spell it out in English terms.

While many new options are introduced at draft 1 (several of which may be removed in later drafts), many of these are "mandatory options." This seeming contradiction allows for future profiles of this standard to specify subset behavior (e.g., an embedded system may not require a filesystem), while not allowing a system that claims conformance to the base standard to opt out of critical sections. (Sorry, Microsoft, if you want to claim conformance, you'll just have to implement it in full!)

One current point of contention is in the inclusion of C Standard interfaces. The intent is to have a single point of reference for a programmer to all standardized interfaces required up to the POSIX level. Don't force that programmer to have to go and look elsewhere for details on a required interface, and present all interfaces in the same style. Several of the interfaces defined by the C Standard are extended by POSIX, and so the inclusion of these is easy to justify. But should we include the entire definition of, say, fopen, or just the extensions to it? The current stand taken is to reproduce the entire interface, but with a warning that if the description conflicts with the C Standard, then this was unintentional, and the C Standard wins. However, this will probably be an item that goes to formal vote of the working group, since there are certainly individuals who believe that this is the wrong way to go about it.

Alongside the Austin Group is a second informal body, known as the Joint Procedures Committee (JPC). The JPC has built a set of rules by which the working group should conduct its business. The basic principle is to achieve consensus around the table. Each of the three organizations taking part (IEEE, TOG, and ISO) has a nominated Organizational Representative (OR). Since the entire principle is to produce a standard that all three organizations can adopt, it is hoped that there will be few points of serious contention. Any individual who believes that a particular problem exists should discuss this with the group as a whole. If necessary, the individual can approach his or her OR to call for a formal vote. Votes are then taken by Organization, with exactly three votes cast. Abstentions are not allowed. In almost all cases, the votes will have a 45-day period, so that each organization can conduct a letter ballot of its members (usually by email).

This is a very exciting time in the Open Systems Standards world. You are strongly encouraged to visit <www.opengroup.org/austin> and join the discussions and reviews.