home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0021.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  3.7 KB  |  75 lines
  1. >From: decwrl!mips!mash@pyramid.UUCP (John Mashey)
  2. Date: Fri, 24 Jan 86 01:22:08 pst
  3.  
  4. It was recently suggested here to make TZ & TERM into u_area variables,
  5. with special system calls to tweak them, using umask(2) as precedent.
  6. 1) Please don't, at least not without much more thought.
  7. 2) Doing umask(2) that way was perhaps a mistake.
  8.  
  9. Let me shed some light on the history of these things, first recalling
  10. some philosophy that UNIXers are supposed to hold dear:
  11.  
  12. Nothing goes in the kernel unless it MUST.
  13. Don't add system calls unless you MUST.
  14. Don't add per-process state, unless:
  15.     a) The kernel needs convenient/efficient access to it.
  16.     OR
  17.     b) It must be there for protection.
  18.  
  19. Way back, PWB/UNIX added 3 per-process data items, which were given
  20. shell variable names.  This was done only after great agonizing.
  21. PWB also changed file creation modes (manually) everywhere to
  22. avoid creating 0666 files; this was not elegant.
  23.  
  24. It was absolutely clear that it was NOT a good idea to keep adding
  25. piecemeal data items to the u-area to cover every single thing
  26. that people wanted, adding new system calls to get/set each value.
  27. By this time [1977], there were all sorts of (different) extra such
  28. goodies tucked away in different UNIX variants, and this was not good.
  29.  
  30. Hence, the environment feature was designed into V7 as a general
  31. mechanism to cover all miscellaneous data, such that:
  32.     a) the kernel never needed to access the data items directly.
  33.     b) Users who wanted big environments could pay for them,
  34.     without penalizing everybody by making the u_area qutie large,
  35.     or by having extra storage mechanisms.  Note: when this was
  36.     done, it was noted that there was "the possibility for untasteful
  37.     expansion of the enviroonment", and this has indeed come to pass,
  38.     as one sees multi-KB-size environments floating around.
  39.     c) No extra system calls were needed.
  40.     d) No protection mechanisms were needed or desired [we designed
  41.     a horde of variants that had the environment as a kernel-protected
  42.     list of name-value-protection tuples; every single one of them
  43.     was ugly, expensive, incomprehensible, or a combination.]
  44.     e) System call interface routines could, as needed, interrogate
  45.     environment variables as needed to provide useful behavior;
  46.     these was deemed greatly preferable to having the variable
  47.     knowledge get wired into the kernel.  [example execvp & friends].
  48.     This was especially true when the semantics might want to change,
  49.     as was the case in figuring out how to use $TERM early on.
  50.  
  51. In some sense, doing umask the way we did was a mistake, since the user
  52. can change it at will, and it could have been implemented via an environment
  53. variable, with appropriate changes to creat.  If I had it to do over,
  54. I'd be strongly tempted to do it this way, although it adds code to
  55. creat(), and the reasonably efficient code wants
  56. to look at the environment once, and cache the initial value.
  57. This has some funny semantics, but could probably be tolerated.
  58. In any case, umask seemed simple enough, and people were, as I recall,
  59. generally thinking that it was tied closely enough to file protection that
  60. it was worthwhile, so it was put in this way.
  61.  
  62. In summary, I again plead with people to seek solutions that avoid 
  63. piecewise additions of u_area state and system calls.  If something
  64. important cannot be done any other way, there is good justification
  65. for doing it.  Otherwise, one is just adding to the overgrowth in there,
  66. rather than helping keep it pruned.
  67.  
  68. [ I always thought that umask should have been per-directory, not per-process.
  69. In 4.2BSD the group of a new file is that of its parent directory.  If umask
  70. worked similarly, I wouldn't have to be always reminding people to use umask
  71. before working on sources.  -mod ]
  72.  
  73. Volume-Number: Volume 5, Number 22
  74.  
  75.