Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0051.txt < prev next >

Wrap

Text File | 1992-02-21 | 16.3 KB | 342 lines

Submitted-by: stephe@lorax.uucp ("Stephen R. Walli") Report on the October 1991 IEEE POSIX Meeting for EurOpen Stephen R. Walli <stephe@mks.com> EurOpen Institutional Representative The October meeting of the IEEE POSIX committees was a strange mixture of administrivia and crankiness. Perhaps it was merely my outlook on the latter. There was no central theme for the week, as there has been in the past with items such as the GUI Wars. The foundation of POSIX was under attack this week in some interesting and possibly necessary ways. These discussions concern options and testability, and options (different) and profiling. The Project Management Committee (PMC) made some carefully worded statements about the continued sponsorship of P1201 (Graphic User Interfaces), the Sponsor Executive Committee (i.e. TCOS-SS Governing Board) meeting was over in record time Thursday night, and we all went home, exhausted as usual. Other items of note include a debate over the upcoming European IEEE POSIX meeting next Fall, and some new work items for consideration. Let's start with the really interesting bits .... 1. Profiles and POSIX.1 There was considerable discussion in the POSIX.1 working group (Base Interfaces) surrounding the old issue of chopping the standard up into chunks of functionality. This discussion centres around the issue of whether or not a profile can point to pieces of the POSIX.1 standard. The POSIX.4 (Real-time extensions) document has its functionality divided up into separate sections, each called out by an option name. For example, if an implementation supports binary semaphores then the symbol _POSIX_BINARY_SEMAPHORES is defined. This makes it very easy for a profile to point to a piece of required functionality in the real-time document. POSIX.1 only supports a few such options for conforming implementations: NGROUPS_MAX, _POSIX_JOB_CONTROL, and _POSIX_CHOWN_RESTRICTED. The POSIX.13 real-time profiling group wants the POSIX.1 standard further optionized to allow its functionality to be called out separately, such as an option for the file system, an option for process control, and so on. This would allow the real-time embedded profile to specify a POSIX.1 style file system, but not require POSIX.1 style process control. The embedded profile cares about threads, or possibly a single process. Nothing so ``cumbersome'' as multiple processes is required. There are members of POSIX.1 who completely disagree with this view of the standard. POSIX.1 defines a portable programming interface which serves a broad range of general applications. It is viewed as a minimal set. Nothing may be removed. POSIX.1 can never be subsetted. Part of this has to do with the sanctity of the term - 2 - ``POSIX''. To the original standards development group, ``POSIX'' means POSIX.1. If you come from the POSIX.2 Shell and Utilities group, it means a POSIX.2 Shell and Utilities environment, which doesn't necessarily require a POSIX.1 system underneath it. Some people are magnanimous enough to recognize it to mean a POSIX.1 implementation with a POSIX.2 Shell, and so on. There is a real concern that anything else isn't POSIX, nor can it use the name POSIX. A terrible vision is painted of the existing DOS environment, i.e. a loader and simple file system, being allowed to call itself POSIX by making functionality optional like process control. Coming relatively recent to the IEEE POSIX standards development world, (I've only been mired in the muck for two years,) I quickly learned to use the term ``POSIX'' to mean a family of standards development projects. Indeed, this is the informal definition discussed in the POSIX.1 standard's introduction. If one wants to discuss POSIX.1 interfaces, one talks about ``POSIX.1''. Likewise, if one is discussing POSIX.6 extensions, one refers to ``POSIX.6'', and so on. This level of naming is required to remove ambiguity. There is also no way to keep marketing departments clear on this. They will continue to misuse and abuse the term ``POSIX''. There is no protection for an ignorant consumer. The standard legislates what needs to be provided to claim POSIX.1 conformance. It cannot police the market place. There is a genuine technical issue with dividing up the POSIX.1 standard. The division would need to be extremely clean and concise. Relevant definitions from one section would need to be carried with functionality discussed in the other sections. Any cross referencing would need to be handled extremely carefully. Considering the current organization and wording used throughout the POSIX.1 standard, it would not be an easy job to pick out new options. This discussion will likely carry on for some time as other profiling work attempts to impact POSIX.1. Already there are profile working groups for supercomputing, transaction processing, real-time systems, multi-processor systems, and a general multi-user this-is-what-UNIX-looks-like profile. I don't believe anything should prevent a future IEEE POSIX standards working group, POSIX.42 for example, developing some narrow but well defined application environment profile for their application domain which leverages off of the POSIX.1 domain. Implementors will implement and claim conformance to POSIX.42. Applications developers will build portable applications using the interfaces in the POSIX.42 profile. If POSIX.1 can subset carefully enough to cleanly and clearly describe pieces of functionality, it should. Future applications development/procurement profiles, such as the U.S. government FIPS 151-1 on POSIX.1, may indeed be based on the POSIX.18 general multi-user profile. Simple. But then nothing is ever simple in POSIX. - 3 - 2. OPTIONS and options POSIX.1 allows implementation variance in a number of ways. The primary implementation options are a well defined, explicit method of allowing implementation variance. These are all named (e.g. _POSIX_CHOWN_RESTRICTED), and have thus been nick-named ``Big-O'' options. The term ``implementation defined'' clearly allows an implementation to do anything it chooses, although there are documentation requirements. Even ``unspecified'' and ``undefined'' are well described. Then things get muddy fast. Some facilities are not necessarily mandatory, and the choice of whether to implement or not is indicated by the use of the term ``may''. For example, an implementation may define certain environment variables, and if it does, they shall mean a certain thing. For other features, an implementation is allowed a restricted choice between two behaviours, indicated by phrasing similar to ``may do A or B''. For example, the behaviour of an interrupted read() after successfully reading some data is to either return -1 and errno is set to [EINTR] or the read() returns the number of bytes read to that point. These later two examples are deemed ``messy'', by the POSIX.3.1 (Test Methods for POSIX.1) working group, and are being documented. They've been nick-named ``little-o options'', as some people feel they should more explicitly be called out as selectable options. The other side of the discussion argues that these are items which no portable application should care about. The wording of the standard allows for the implementation to choose its own path. It acts as a caveat to the application developer to not depend upon the exact nature of the behaviour. This discussion will likely heat up over the next meeting or two. 3. P1201 Continues When last we left our story, the Project Management Committee (PMC) of the IEEE POSIX sponsor executive committee (SEC) was left to recommend a suitable fate for the P1201 project on graphic user interface standards. A motion had been made to withdraw sponsorship from the project. P1201 consists of two projects. P1201.1 is developing a windowing user interface toolkit specification. It has a long history of bloodshed between Open Look and OSF/Motif supporters. P1201.2 is developing a guidelines document on recommended drivability practice. A style guide for ``feel'', rather than ``look''. Separate competing project requests were brought forward in the Spring 1991, one to standardize the OSF/Motif API and - 4 - Style Guide, and the other to standardize the Open Look API and Style Guide. The IEEE Standards Board (POSIX's parent committee) considered that the functionality overlap between the two proposed work items and also with the work of P1201.1, was an insufficient reason to refuse project sponsorship. At the July 1991 meeting, the POSIX working groups refused to undertake sponsorship of these competing projects for other reasons. The work was considered too immature to standardize it. It was then moved that sponsorship be removed from P1201 because it suffers the same flaws. This motion was handed to the PMC to recommend action for the October meeting. P1201.1 requested a revision of its scope of work, and is working toward a simpler higher-level API specification. They have made real progress over the past two meetings (July and October) with the contentious members off chasing their own project requests. (Incidentally, these project requests are still being pursued in dank dark corners of the IEEE standards hierarchy.) The revised scope was recommended for approval, and the project will be reviewed again in three meetings. P1201.2 has been making steady progress all along. They are hoping to go to ballot in the not too distant future. Continuation of their work was recommended. P1201 is allowed to proceed. It all seemed entirely to quiet and straight forward, considering the history of the past two meetings. Maybe we're maturing. To pull the plug on these working groups at this point would be a mistake. In a few years time, there will clearly be a need for such a standard, and the technology will be very mature (read: ripe for standardization). It will be very difficult to get employers to support such an effort, spending the money to keep people involved, if the initial effort is closed without anything tangible to show for it. 4. European Meeting in October 1992 The IEEE has a desire, as a ``transnational'' organization, to have its standards development groups meet every other year somewhere other than the United States. The intent is to gather international input into its standards development process. This is very important to POSIX, considering its ISO development stream as an international standard being developed by a national member body. (The American National Standards Institute, ANSI, delegated responsibility for the POSIX standard's development back to the IEEE.) There was a lot of resistance to meeting in Europe in the Fall of 1992. The problems centre around corporate approval and money. Many corporate authorities don't view trips to Europe as ``work''. They still think POSIX is some kind of conference. They don't appreciate that it is a standards development working group. Many American hotels, large enough to support the 350 - 5 - working group members with about 25 to 30 meeting rooms, do not charge for the meeting rooms. They make their money from serving lunch and coffee. European hotels apparently charge for meeting rooms regardless of lunch and room bookings. This means that the meeting registration will likely be at least twice the normal $250 US. Add to this a trans-Atlantic airfare, and a higher per deum, and managers start getting real uncomfortable approving the funds. Historically, the last meeting was held in Brussels in October, 1989. It did not draw a lot of European response. The European response that it did draw was not sustained past that meeting in many cases. Many working groups are loath to go the effort of gaining corporate approval for a European meeting, if it's not going to bring in the desired European participation. On the other hand, if a large European contingent does show up, some POSIX working groups are concerned that their work agendas will be affected, while they adjust to bringing an influx of new blood up to speed on the issues. They want to have their cake and eat it too. The current decision is to continue to pursue a meeting in Europe. A likely candidate country is the Netherlands. Ideas to defray some of the costs include: -- holding seminars prior to the POSIX working group meetings on POSIX related topics, -- requesting the IEEE Computer Society pick up the additional expenses, (on the order of $70,000 US.) -- charging individual attendees the additional money to attend. I would love to hear from EurOpen members any suggestions, ideas and preferences regarding this subject. How high is European interest in an IEEE POSIX working group meeting? 5. New Work Items for Consideration A number of new topics are being raised as potential candidates for standardization by the IEEE's Technical Committee on Operating Systems -- Standards Subcommittee (TCOS-SS). This is the full proper name of the committee responsible for the POSIX working groups. Two of these candidates come from outside of the IEEE realm. The SPECmark consortium has approached the IEEE with the idea of making the SPECmark performance benchmarks an industry standard. There may be a formal presentation by the SPECmark consortium at January's IEEE POSIX meetings, but the general feeling was that standardization of this work belonged elsewhere. A second outside proposal was from the Rock Ridge group. These people are standardizing on an optical disk standard. (This work should not be confused with the ANSI X3B11.1 WORM standard work. Please see Andrew Hume's X3B11.1 working group report in the Jan./Feb 1992 issue of ;login: or in comp.std.unix.) There is the desire to place a POSIX.1 file system on a Rock Ridge disk, and therefore an interest in input from the POSIX working groups. It was again felt that - 6 - this work would better be done at arm's length, with appropriate liaisons in place. The final new work item came from within. The Distributed Systems Steering Committee (DSSC), which overseas all of the network related standards in TCOS-SS, has proposed forming a working group to develop a standard for secure distributed computing. Depending upon who you talk to, this means Kerberos or definitely-not-Kerberos. It will likely start as a simple Birds-of-a-Feather meeting at the January IEEE POSIX meeting. If there's enough interest, a real study group will be formed to meet at the April POSIX meeting for the week. The result of such a meeting would be a project authorization request (PAR) to be presented to the Project Management Committee (PMC) in July. The PMC is a sub-committee of the Sponsor Executive Committee (SEC), which is the controlling committee of TCOS-SS. If the PMC recommends sponsorship, the SEC will ratify it with a vote. The study group would become a real standards working group of TCOS-SS, with its first formal meeting as ``early'' as the October POSIX meeting. Thus are standards born. Volume-Number: Volume 26, Number 62