home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0086.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  4.1 KB
  1. From: mcvax!sphinx.co.uk!domo@seismo.UUCP (Dominic Dunlop)
  2.  
  3. Nice to see SAS on the net -- although your sales people play coy about if
  4. and when a UNIX implementation might see the light of day  (no, I'm not
  5. asking you to comment...)
  6.  
  7. In article <166@sas.UUCP> you write:
  8. >Is there any effort in the standards efforts to provide kernel (or CRT lib.)
  9. >support for this [dynamic loading/execution from data space]?
  10.  
  11. No.  To my knowledge it hasn't come up at all on POSIX (although I didn't
  12. attend last week's meeting in Seattle).  Not least of the problems is that
  13.  
  14.  1.  The classic BSD implemenataion depends on a highly machine-dependent
  15.      aspect of VAX memory management.
  16.  
  17.  2.  Quite a few people (and I'd probably number myself among them)
  18.      consider this aspect of VAX memory management to be brain-damaged, or
  19.      at least to be something which could be done better by throwing a few
  20.      more gates at the problem (gates weren't so cheap or fast in 1978).
  21.  
  22.  3.  Later memory management implementations may well specifically
  23.      exclude ``doing things the VAX way'' because it is judged to be
  24.      unclean and/or unsafe.  Certainly, many 68x00 implementations don't
  25.      allow execution out of data space, and don't provide a kernel call
  26.      which (in effect) allows programs to move the boundary between text
  27.      and data.
  28.  
  29. Consequently, any attempt to introduce the topic to POSIX would be
  30. controversial, and POSIX does not need controversy if a standard is to be
  31. ratified on schedule!
  32.  
  33. To put it another way, this is a political issue...  However, if you were
  34. to make a more or less formal proposal by mailing John Quarterman,
  35. moderator of comp.std.unix (std-unix@ut-sally) you could flag a valid
  36. technical issue as open, and might even get a formal reply from the working
  37. group.
  38.  
  39. If you want to rope in somebody with heavy-duty experience of this issue,
  40. Catalytix Corp. of Cambridge MA (phone 617 429 2160 -- I don't have a net
  41. address) have had to fight it in bringing up their Safe-C interpreter in
  42. a variety of UN*X and other environments.  (Safe-C is worth checking out
  43. if you're a developer, anyway.)
  44.  
  45. The usual disclaimer: I don't speak for IEEE working group 1003.1 -- almost
  46. nobody can (in fact, the IEEE carries professional liability insurance
  47. just in case anybody wants to brief their lawyer to argue about it).  These
  48. opinions are strictly my own.
  49.  
  50. [ The quickest way to make a proposal to IEEE P1003.1 (the POSIX committee)
  51. is to mail a paper copy to
  52.  
  53.     Secretary, IEEE Standards Board
  54.     Attention: P1003 Working Group
  55.     345 East 47th St.
  56.     New York, NY 10017
  57.  
  58. Formal notes to the committee have to go there, anyway, or be carried to
  59. a Working Group meeting.  Feel free to submit a copy to comp.std.unix
  60. if you want to.
  61.  
  62. As decided at the Seattle meeting (22-26 June 1987),
  63. all proposed changes to the P1003.1 draft standard must be
  64. in the form of balloting objections, i.e., actual proposed
  65. wording for the standard with attached rationale is required.
  66.  
  67. You can still send in general comments, though.  Also, your note
  68. might get redirected to another subcommittee which is more
  69. directly addressing related issues.  Offhand, I don't know
  70. which one that might be: perhaps one of the /usr/group
  71. Technical Committees.
  72.  
  73. I play several roles related to POSIX, and they frequently get confused:
  74. a) Moderator of comp.std.unix.
  75. b) Institutional Representative from USENIX to IEEE P1003.
  76. c) Member of the USENIX Board of Directors.
  77. d) Private contractor for the P1003.1 Rationale, funded by /usr/group.
  78.  
  79. a) is largely a result of b), and c) is useful in doing b).
  80. d) is completely unrelated to the other three, and is finished.
  81.  
  82. I can and sometimes do submit notes to P1003 as the USENIX
  83. Institutional Representative (e.g., the tar vs. cpio note).
  84. It's one of my functions in that role to gather information
  85. from the USENIX membership and the public and also to distribute
  86. information about POSIX and other standards.  So, I could submit
  87. a note for you.  It will just get there faster if you do it yourself....
  88.  
  89. Dominic's disclaimer about speaking for IEEE or P1003 also
  90. applies to me, of course.
  91.  
  92. -mod ]
  93.  
  94. Dominic Dunlop, Sphinx Ltd.    UKnet:    domo@sphinx.co.uk
  95.  
  96. Volume-Number: Volume 11, Number 87
  97.  
  98.