The Future of POSIX
by Nicholas M. Stoughton
Those of you who follow this column regularly know about the debate that has been continuing in the IEEE Portable Applications Standards Committee (PASC) for the last year or so: What is POSIX? Does it have a future? If so, what is it and how do we get there?
In July this year, the ad-hoc group that was set up to investigate and report on these issues produced its final report. This report is reproduced below. Closer cooperation between the three groups that have up until now been responsible for producing standards with overlapping scope now looks certain to happen.
The three groups, PASC, ISO JTC1/SC22/WG15, and The Open Group (TOG) met together in early September to start work on a revision to POSIX.1 and POSIX.2. The idea is to produce a single document that will define the core of the Single UNIX specification, and replace POSIX.1 and POSIX.2 as they are today with a more up to date and complete standard. This is the first meeting of the study group proposed in the report. This study group is responsible for planning, scoping, and initiating a new joint working group to produce these new standards. This represents the future of the core POSIX work.
Much of the recent POSIX work has been in relation to the realtime extensions, which are still recognized as vitally important, and a place where PASC expertise is still essential. In order to finish those realtime extensions not yet completed, POSIX.1a and POSIX.2b must clear the way for them. Both of these documents are in ballot at present, and look likely to complete within the next year. Apart from providing a basis for the other realtime extensions, these documents will add several classic UNIX features, such as symbolic links, to the existing core.
Let's hope that we can now stop wondering quite so much about what the future holds for us, and instead get on with implementing it!
The Report of the Ad-Hoc Committee
At the April, 1998 meetings PASC, WG15 and The Open Group (TOG) all committed to seeking answers to the procedural, political, financial, and intellectual property issues which must be addressed to enable the coordinated development and maintenance of POSIX standards. However, proposing solutions, or even identifying who should be involved with specific negotiations, has proven to be very difficult.
The April 1998 preliminary report (N719) from the POSIX Coordination Ad-Hoc Committee identified three "First Principles":
This Final Report proposes some basic resolutions intended to define the way forward and provide a "stake in the ground" for resolving the numerous issues which must still be addressed.
In previous debates we have agreed that the existing "rolling amendment" process for POSIX standards is no longer acceptable. We have further agreed that we must establish a step-wise revision process. In January 1998, we took initial steps toward that goal by resolving to limit possible amendments to POSIX.1 and POSIX.2 to some of the existing projects and corrigenda. We further resolved to develop all other POSIX standards as stand-alone specifications that could, as appropriate, be included in a future revision of the base standards.
The 1984 /usr/group Standard was the first effort to define a single, common specification for the various UNIX implementation versions which had evolved in the commercial and academic arenas. This standard, along with AT&T's System V Interface Definition, were used as the basis for the IEEE/TCOS efforts to develop POSIX standards. In the same time frame, X/Open, in close cooperation with the POSIX committees, developed its series of Portability Guides (XPG). The extraordinarily close cooperation between these two efforts has resulted in the incorporation of all POSIX.1 and POSIX.2 concepts and features (including many which were contributed by TOG) in TOG's Single UNIX Specification (SUS). Today, the POSIX.1 and POSIX.2 base standards and the SUS are very closely aligned. The SUS represents valuable input to the revision project proposed below.
We urge PASC and the WG15TAG to endorse the following proposals at their July 1998 meetings, the TOG liaison to obtain TOG concurrence, and WG15TAG to submit this proposal to WG15 for its approval. It is essential that these agreements be achieved by the end of July, 1998. The SC22 TAG can then provide the information to the SC22 plenary in August when SC22 is expected to take up the issue of the future of WG15.
There are a number of issues that led to this proposal:
In addition, there are numerous unresolved issues that must be addressed if we are to achieve the three "first principles" that we identified at the beginning of this report. Some of these unresolved issues are:
Hammering out the details of these and other issues will continue to be a very major and difficult problem. The ad hoc committee stresses the importance of recognition by all parties that "the devil is in the details" and there are many details remaining to be addressed. The concerns raised by the lack of resolution of these details must be overcome if progress is to be made.
Recognizing the "realities" of the current situation, but also acknowledging the continuing importance of POSIX standards in the quest for truly open systems environments, we therefore re-affirm the Issues and Recommendations presented in the preliminary ad hoc report and further propose the following actions:
This report is the result of approximately 12 hours of face-to-face meetings, ongoing electronic discussions over the last six months, and many hours of private discussions on the part of approximately 20-25 participants from all three organizations. The frank and open discussions of the ad hoc committee should be continued in all three organizations. I extend my personal thanks and appreciation to everyone who participated in these discussions.
Roger Martin, chair, POSIX Coordination ad hoc Committee.
The PASC working groups have been responsible for delivering many standards projects successfully over the years. Occasionally, however, we embark upon a project that ends up deadlocked for any number of reasons, and fails to make any headway for an extended period of time. Although these projects have their own constituency who are committed to the results of the project, if that project cannot complete in a timely fashion, those constituents will end up looking elsewhere. From time to time, projects end up so helplessly deadlocked that they cannot make sensible progress. Additionally, standards projects, at least in the IEEE, are staffed entirely by volunteers, and these volunteers sometimes lose the time that they dedicate to progressing standards work to other projects their employers demand.
As a result some standards projects end up in a stagnant form, with no visible progress even to those who are looking closely. It serves the community as a whole if such stagnant projects are actually withdrawn, rather than remain unfinished. This year, we have withdrawn sponsorship for POSIX.1e and POSIX.2c (security), and at the July meeting for POSIX.14 and POSIX.18 (Multi-processing Profile and "POSIX" profile) were also withdrawn.
Each quarter, projects that seem to have remained static for more than a year will be given a warning that unless they can show some sign of life, they will have their sponsorship withdrawn at the next meeting. Of course, withdrawal of sponsorship is not in itself a death sentence. If those concerned are actually doing something worthwhile, they can always reapply for sponsorship.
Common Information Model for UNIX
The Open Group's System Management working group (TOG SysMan) has spent much of the last year contemplating what to do in the context of TOG's "IT Dialtone" initiative. It must be said that very little real progress has been made on this; lots of words and pictures, an architecture document, but little that will really effect anybody! One thing that has emerged from this is a commitment to making the Desktop Management Task Force (DMTF) Common Information Model (CIM) a keystone for future system management work. Information about CIM is available at <http://www.dmtf.org/cim/>.
CIM is a conceptual information model for describing management that is not bound to a particular implementation. This allows for the interchange of management information between management systems and applications. This can be either "agent to manager" and "manager to manager" communications which provides for Distributed System Management.
This is the first time in this industry that a common method of describing management information has been agreed and followed through with implementation. Other efforts have failed because of the lack of industry support. The model, because it is implementation independent, does not provide sufficient information for product development. It is the specific product areas, applications, system, network, database and devices and their product specific extensions that produced workable solutions.
In July, at Miami, SysMan agreed to sponsor a project to provide UNIX-98 extensions to the CIM common system schema.
CIM schemas are described in Managed Object File (MOF) format. The CIM-UNIX project team are writing a MOF description of the things that are in UNIX-98, but are not represented in the CIM common system schema. For example, there is a UNIX_FileSystem class, based on the CIM_FileSystem class, but adding features such as the total number of Inodes and Free Inodes (known as "slots" in UNIX-98, to avoid implementation specific language).
A variety of vendors are producing tools that use CIM already; standardized UNIX extensions will make these tools even more powerful and useful in managing a heterogeneous network. CIM is a part of the DMTF Web Based Enterprise Management (WBEM) initiative; in fact at present, CIM is the only approved WBEM specification.