What is POSIX?

Lowell Johnson <Lowell.Johnson@unisys.com> reports on the November 18, 1997 "What is POSIX" ad hoc meeting in San Jose, CA.

The ad hoc meeting began at 4:30 after various meetings of the IEEE Computer Society were finished. My notes follow because there was no secretary. Considerable discussion had occurred before 4:30, with various collections of people participating.

The problem as I understood it was simply, "What is inside the box we call POSIX?" Various presentations were made by the participants. It is very easy to make generalities that hide the truth. For example, it was claimed that the people working on standards now are not representative of "the community."

One early proposal was that all existing 1003.x standards be frozen. New work could still be called POSIX, but would have new numbers. Checkpoint Restart might be numbered 1777, but it would still be called POSIX. The frozen set would become the "core POSIX."

This position seemed surprising to me. There are several standards already published (such as the Realtime extensions) that go beyond the original "core" standards of POSIX.1 and POSIX.2. However, almost everyone agreed that the existing published POSIX standards should be left alone, and new numbers should be used for new standards. Only one person spoke up and said he would "prefer" to roll back to the core standards, but he realized it was impractical to do that because it would be too much work.

There was a long discussion about how you could have a standalone standard that did something like modify read(). This was thought to be part of the topic of another ad hoc group, but it was agreed that the standalone standards could not change any code in the base standards.

One suggestion was to leave all currently sponsored projects, whether complete or no, in the POSIX circle. However, this was felt to be inappropriate.

A question was directed at checkpoint/ restart: how much work would it be to make it a standalone document? The chair said it would break the group, but one member said she did not think it modified any part of POSIX.1 [Editor's Note: When checkpoint/restart was a part of POSIX.1a, it touched many parts of core POSIX.1, particularly fork() and exec()]. Several groups need to evaluate how much work it would be to change to a standalone document.

A list of projects to be included in this new core standard was agreed upon:

These are IN	These are OUT
1003.1 1003.2	1003.1a 1003.2b
1003.1b 1003.2a	1003.1d 1003.2c
1003.1c 1003.2d	1003.1e
1003.1g	1003.1h
1003.1I	1003.1m
1003.1n	1003.1q

It was agreed unanimously that a resolution must be based on a list of projects, not on any sort of cutoff date. It was also agreed that a vote will have to be taken at the SEC meeting. Some people need to do some homework to find out how much work it would take to change the proposed standalone projects to be standalone documents.

Finally, we debated what the results of this meeting really were, and after considerable debate, the following compromise emerged: I will report on what we agreed and what we did not agree on. At the January SEC meeting, a motion will be made to limit the core POSIX to the above list of standards.

After a reasonable amount of debate, and possible amendments, a vote will be taken. Then I and the appropriate WG chairs will take the necessary action with the affected projects.

All items not included on the list should have sponsorship withdrawn, but they could be resubmitted at the same meeting with a new number (not 1003.x). A final discussion reiterated the requirement that no future standard can break this core POSIX. This was agreed to be an absolute rule, regardless of the result of division issue. This means, for example, that anyone who adds to common functions like read() or write() must be able to fully document the enhancements without changing anything in the core standards.