home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0051.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.9 KB
  1. From: gwyn@brl.arpa (VLD/VMB)
  2. Date:     Sat, 11 Oct 86 7:06:31 EDT
  3.  
  4. The current 1003.1 job control proposal is specifically OPTIONAL for
  5. POSIX-conforming systems, partly at my insistence two meetings back.
  6. The idea is to provide a standard for this feature, even though it is
  7. not universal, simply because many vendors feel pressured to provide
  8. Berkeley-style job control.  I believe H-P already has this in their
  9. SVID-compliant system, HP-UX.  Note that the hooks for this are not
  10. quite the same as in 4BSD, due primarily to System V compatibility
  11. constraints.
  12.  
  13. Several of the recent 1003.1 RFCs and proposals have been aimed at
  14. those areas where traditional AT&T-supplied UNIX has been perceived
  15. as sufficiently weak that other sources (mostly Berkeley) have come
  16. up with features to fill the gap.  These areas include reliable
  17. signals, extent-based file systems, enhanced terminal handler user
  18. interface, and Berkeley-style job control.  Practically all such
  19. ideas have been iteratively discussed and revised before being added
  20. to the POSIX standard document; some are still not adopted but may be
  21. approved for POSIX within a meeting or two.  (I must commend the
  22. committee members and other corporate staff, from H-P and Sun
  23. particularly, who have invested much time in working out the details
  24. of such proposals.)
  25.  
  26. I hope that the BSD futures planners seriously consider IEEE 1003
  27. compliance for future releases.  That would greatly help their "VAR"
  28. customers (i.e. system vendors) and UNIX programmers in general.
  29. (We have taken quite a bit of trouble to keep BSD systems in mind
  30. when drafting the 1003.1 POSIX standard.)  AT&T's bone-headed SVR3.0
  31. licensing restrictions have suddenly made POSIX conformance an
  32. attractive alternative to SVID compliance in the commercial marketplace,
  33. and it should be obvious why a neutral industry standard would be well
  34. received by government agencies, not to mention by AT&T's competitors.
  35. Support from Berkeley would mean a lot at this stage.
  36.  
  37. Streams a la DMR would be terrific; however, please keep in mind that
  38. the 1003 WG is not tasked with designing an ideal operating system,
  39. but rather with standardizing a useful interface to a closely related
  40. family of operating systems.  If we strive for the ideal design before
  41. publishing a standard, it will be too late to do any good, and vendors
  42. won't get their systems to conform very soon if ever.  There is room
  43. for future extensions to the standard (which perhaps could be better
  44. structured for this purpose), and indeed there are real-time, signals,
  45. and shell/utility working groups and subcommittees working on some of
  46. these areas already.
  47.  
  48. As far as multiplexing goes, one can't reasonably leave that to user
  49. mode even with DMR streams; context switching is too expensive.  We've
  50. been running a version of "mpx" (DMD layer host manager) that uses
  51. select() to multiplex in user mode, and it is noticeably slower than
  52. kernel-mode multiplexing.
  53.  
  54. Volume-Number: Volume 7, Number 52
  55.  
  56.