home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0071.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  9.9 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.  
  5.             An Update on UNIX* and C Standards Activities
  6.  
  7.                             December 1989
  8.  
  9.                  USENIX Standards Watchdog Committee
  10.  
  11.                    Jeffrey S. Haemer, Report Editor
  12.  
  13. IEEE 1003.8/1: POSIX Transparent File Access Update
  14.  
  15. An anonymous correspondent reports on the July 10-14, 1989 meeting, in
  16. San Jose, California:
  17.  
  18. [Editor's note -- Though this report came in substantially later than
  19. the other July reports, I think it's still useful, provocative, and
  20. well worth reading. -jsh]
  21.  
  22.                  Overview of New 1003.8 Developments
  23.  
  24.   1.  All standards produced by POSIX committees (with the exception
  25.       of language-binding standards like 1003.5 and 1003.9) must be
  26.       specified in a language-independent fashion, and must include at
  27.       least one language-specific binding.  Since P1003 will not have
  28.       guidelines and rules for constructing a language-independent
  29.       specification before April 1990, no POSIX networking group can
  30.       possibly ballot a document before July 1990.  "Mock" ballots
  31.       (aka trial-use ballots) are unaffected by this, but their
  32.       usefulness will be diminished.
  33.  
  34.   2.  Two new POSIX Networking working groups either have submitted or
  35.       will soon submit PARs to begin work, bringing the total number
  36.       of POSIX Networking working groups to six.  These new groups are
  37.       the Name Space and Directory Services Interface and the X.400
  38.       Mail Gateway Interface.  [Editor's note -- The SEC approved the
  39.       PAR for the former, but decided that the latter transcends
  40.       POSIX, and recommended that the IEEE form a separate, numbered
  41.       group, analogous to 1003 or 1201, to handle X.400.  See below.
  42.       -jsh]
  43.  
  44.   3.  Due to the rules governing IEEE and IEEE-TCOS standards
  45.       activities, as well as the logistical nightmare six sub-working
  46.       groups cause, the hierarchical structure of the P1003.8 POSIX
  47.       networking committee will be flattened out, with each current
  48.       sub-group submitting PARs to cover their current work.
  49.       Coordination will be provided by a "POSIX Networking Steering
  50.       Committee", made up of the chairs and vice-chairs of each
  51.  
  52. __________
  53.  
  54.   * UNIX is a registered trademark of AT&T in the U.S. and other
  55.     countries.
  56.  
  57. December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
  58.  
  59.  
  60.                                 - 2 -
  61.  
  62.       networking-related working group and the current chair and
  63.       vice-chair of 1003.8.  [Editor's note -- This is still being
  64.       debated by the SEC. -jsh]
  65.  
  66.   4.  Since each of the 1003.8 sub-groups will be submitting separate
  67.       PARs, the P1003 Sponsor's Executive Committee (SEC) is taking
  68.       the opportunity to evaluate the degree to which each PAR is
  69.       intended to represent a part of the "POSIX Environment" or is a
  70.       component which has no relationship to the rest of POSIX and
  71.       should, hence, stand alone.  The result of this is that several
  72.       of the 1003.8 sub-groups may be issued project numbers outside
  73.       of the P1003 family.  There is some precedent for this; the X11
  74.       interface group was assigned project number P1201 for just this
  75.       reason.
  76.  
  77.                Activity in the TFA Subgroup, P1003.8/1
  78.  
  79. The group is making slow but steady progress towards the goals of a
  80. fully-specified programmatic interface for networked file access and
  81. the semantics and suggested syntax for administrative interfaces for
  82. such a functionality.  The group is dominated by a faction, apparently
  83. lead by Sun Microsystems, with a goal of ensuring that NFS, in some
  84. form, is a sufficient mechanism to provide the service required by the
  85. "full TFA" interface.  The balance of the committee is composed of
  86. people who simply want a standard they can use as an acquisition tool.
  87.  
  88. Achievements
  89.  
  90.    + Enough consensus and material was obtained to permit development
  91.      of a first draft of the programmatic interface part of the
  92.      specification; this draft should be complete in time for the
  93.      second mailing, due out on September 8.
  94.  
  95.    + Liaison activities with 1003.7 (System Administration) continued;
  96.      .7 indicated that all of the options for the TFA mount/unmount
  97.      model were, in fact, of use in administering such a system.  They
  98.      also agreed that they owned responsibility for all file-system
  99.      commands not completely unique in function to TFA, and that they
  100.      would pursue input from the TFA group when the time was right.
  101.  
  102.    + Further progress was made on identifying status and usage
  103.      information which must be obtainable from the provider of a TFA
  104.      service.
  105.  
  106. December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
  107.  
  108.  
  109.                                 - 3 -
  110.  
  111. Problem Areas
  112.  
  113.   1.  Representation in the group is unbalanced; there is, as of this
  114.       time [Editor's note -- July, '89 -jsh], no substantial
  115.       representation of the "stateful" side of the semantic issues.
  116.       The chairman has, so far, been unsuccessful in encouraging a
  117.       more balanced group viewpoint so representation from the
  118.       stateful camp has been solicited (with minimal success) for
  119.       future meetings.
  120.  
  121.   2.  Several "grey areas" in the semantics of IEEE 1003.1-1988 have
  122.       been identified by the TFA group over the last several months.
  123.       The suggested "fixes" have been slanted in a way that would let
  124.       the TFA interface avoid relaxing 1003.1 semantics while
  125.       permitting a stateless implementation of the TFA service; i.e.
  126.       rather than strengthening 1003.1 to define the actual behavior
  127.       of a single stand-alone system, the proposals have been so weak
  128.       that they underconstrain single-system behavior.  It appears
  129.       that the majority of the 1003.1 committee will not approve of
  130.       this approach, and will require the "fix" to be of the proper
  131.       strength to correctly specify single-system behavior.
  132.  
  133.       Let me give an example.  The original 1003.1 standard is silent
  134.       on the issue of when the effects of a write are visible to a
  135.       subsequent read of the same byte of the file.  If process A
  136.       writes byte 123 of file "foo", then process B does a read of
  137.       byte 123 of file "foo", at what point is B guaranteed to see the
  138.       byte A wrote?
  139.  
  140.       Immediately?  If so, stateless solutions employing read caches
  141.       fail; if process B is remote on system "bsys" and reading the
  142.       file via NFS, byte 123 might come out of the file cache on bsys
  143.       and not from the file cache on the system where A lives.
  144.  
  145.       Immediately if A and B are on the same system, and at some
  146.       implementation-defined time otherwise?  This requires 1003.1 to
  147.       define what it means by "the same system", and doesn't
  148.       adequately address multi-processor single systems with
  149.       "interesting" caches.  It also means a truly portable
  150.       application that is interested in running in a distributed
  151.       environment can *never* know when the byte written by A is
  152.       visible to B.
  153.  
  154.       Only in the presence of byte locking?  In other words, A locks
  155.       byte 123, writes it, unlocks it; if B then locks and reads 123,
  156.       it is guaranteed to see what A wrote.  Not a bad solution, but
  157.       it breaks existing applications and in fact is a relaxation of
  158.       the intended semantics of 1003.1.
  159.  
  160.       Basically, the "intent" developing in 1003.1 is that the effect
  161.       of the write must be seen immediately by any other process with
  162.  
  163. December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
  164.  
  165.  
  166.                                 - 4 -
  167.  
  168.       that file open, without regard to process location, without
  169.       recourse to O_SYNC mode opens, without the necessity for
  170.       locking, and so on.  1003.1-1988 is silent on the issue; the
  171.       proposed fix from TFA (basically a compromise I did not like and
  172.       knew would fail) was that read-after-write be guaranteed only
  173.       for co-located processes and in the presence of locking.  This
  174.       gave 1003.1 a chance to avoid relaxing their intended semantics
  175.       while leaving TFA a "loophole" to change semantics without
  176.       having to indicate a change in wording from 1003.1.
  177.  
  178.       This is what got rejected by 1003.1, which is getting pretty
  179.       damned tired of TFA's trying to claim that the full TFA
  180.       semantics are "just like" 1003.1 but with gaping differences
  181.       that are introduced silently due to weak or weasel wording in
  182.       1003.1-1988.
  183.  
  184.   3.  1003.7, System Administration, is making distressingly slow
  185.       progress.  If this continues, 1003.8 will have two choices with
  186.       respect to client-side administrative commands:
  187.  
  188.          - Do not standardize them; give feedback to 1003.7 and wait
  189.            for them to complete their specification.  This risks
  190.            incompatible implementations.
  191.  
  192.          - Standardize them insofar as they relate to TFA
  193.            administration.  This risks incompatibility between the TFA
  194.            aspects of those commands and their more general aspects.
  195.            An example is the "mount" command; if 1003.7 is unhappy
  196.            with the form of the TFA mount command, they are under no
  197.            constraint to remain compatible with it.  If the group
  198.            ballots far enough in advance of 1003.7, this sort of clash
  199.            could be frequent.
  200.  
  201.   4.  Many of the contentious issues have been "resolved" through the
  202.       various mechanisms POSIX provides for introducing optional
  203.       behavior; most frequently, these involve either
  204.       "implementation-defined" behavior, or the addition of path-
  205.       specific attributes whose status can be determined through the
  206.       pathconf() function.  Several of these options should be viewed
  207.       by the ballot group as being "gratuitous" in some sense, i.e.
  208.       the TFA committee should take a stand one way or another, and be
  209.       willing to be beaten up in ballot for it.  The POSIX standards
  210.       are wishy-washy enough without the addition of gratuitous
  211.       options.
  212.  
  213. December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
  214.  
  215.  
  216. Volume-Number: Volume 17, Number 80
  217.  
  218.  
  219.