home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / unix / 498 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  4.1 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: stephe@usenix.org (Stephen R. Walli)
  3. Newsgroups: comp.std.unix
  4. Subject: Standards Update, POSIX.14: Multiprocessor Profile
  5. Date: 29 Dec 1992 14:24:23 -0800
  6. Organization: USENIX Standards Watchdog Committee
  7. Lines: 71
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1hqj6nINN9fh@ftp.UU.NET>
  11. Reply-To: std-unix@uunet.uu.net
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: stephe@usenix.org (Stephen R. Walli)
  16.  
  17. Rick Greer <rick@ivy.isc.com> reports on the October 19-23, 1992
  18. meeting in Utrecht, NL:
  19.  
  20. The big news in the POSIX.14 working group is that we have inherited
  21. the POSIX.18 draft from Donn Terry and are now responsible for seeing
  22. it through balloting.  POSIX.18 is the Platform Environment Profile,
  23. more commonly known as a profile to describe the traditional
  24. multi-user Unix platform.
  25.  
  26. Having been assured that the POSIX.18 document was ``practically ready
  27. for balloting,'' we traded POSIX.14's March 1993 balloting slot to
  28. POSIX.18. Remember that this year there are so many documents in
  29. ballot that a strict timetable is being used to control the potential
  30. administrative overload.  Our document's ballot slot had been
  31. allocated as a purely defensive measure anyway - see below.  We also
  32. decided to keep the balloting group open right up to the last minute,
  33. so those interested in paying $25.00 for the privilege of complaining
  34. may still do so.  [Ed. - This may be raised to $50.00 in the new year!]
  35.  
  36. We made one major change to the POSIX.18 draft: The C language feature
  37. is now required. It had been optional.  Our reasoning for this was
  38. twofold.  First, we realized that because there was no requirement
  39. that a given implementation provide a specific language feature,
  40. people could write POSIX.18 compliant applications that would not run
  41. on POSIX.18 compliant implementations!  By requiring C at a minimum,
  42. vendors can guarantee portability of other languages, in particular
  43. FORTRAN and ADA, to all POSIX.18 compliant implementations by writing
  44. their runtime libraries in C.
  45.  
  46. Secondly, given that POSIX.18 is supposed to codify ``classic UNIX,''
  47. and since classic UNIX has always included a C compiler; albeit the
  48. ``classic'' K&R compiler, not c89; we felt it appropriate to require C
  49. language support in POSIX.18.
  50.  
  51. The working group also made a number of minor editorial changes to the
  52. document, mostly removing redundant text, which brought it down to
  53. less than half its original size!
  54.  
  55. As for POSIX.14's real purpose, the POSIX multiprocessor profile, we
  56. decided not to ballot the current draft after all.  We had originally
  57. decided to put POSIX.14 out to ballot in March in an attempt to be in
  58. ballot by the time the Profile Steering Committee (PSC) finalized its
  59. rules for ``Standard Posix Profiles.'' We reasoned that if profile
  60. groups that were in ballot at the time the rules were adopted were
  61. grandfathered in such a way as to allow them to ignore said rules,
  62. POSIX.14 might be the only profile to which the rules applied. This
  63. seemed a bit unfair.
  64.  
  65. It now appears, however, that all profiles will have to follow the PSC
  66. rules before they can come out of ballot.
  67.  
  68. So we're back to proposing new MP interfaces for POSIX.1 and POSIX.2
  69. that would fill various semantic gaps in MP systems that will be noted
  70. in the POSIX.14 draft.  This includes describing parallel behavior for
  71. a number of common utilities (e.g, make, find, grep, xargs,) as well as
  72. describing special MP features of system administration functions such
  73. as ps(1) and times(2).  We also continue to argue about processor
  74. binding: Can we specify enough of this in an architecture- independent
  75. manner to make it worthwhile.
  76.  
  77. One interesting point made at the October meeting was that many of the
  78. participants in our working group feel that our major contribution
  79. will not be the MP profile, so much as our monitoring of other POSIX
  80. work to make sure that any new interfaces do not cause major headaches
  81. for MP implementations (e.g, the work that we've already done with
  82. respect to pthreads).  With this in mind, we have proposed a new name
  83. for the group: POSIX.14 - the POSIX reentrancy police!
  84.  
  85. Volume-Number: Volume 30, Number 8
  86.