TZ and TERM per process

[Moderator, John Quarterman]

>From: decwrl!mips!mash at pyramid.UUCP (John Mashey)
Date: Fri, 24 Jan 86 01:22:08 pst

It was recently suggested here to make TZ & TERM into u_area variables,
with special system calls to tweak them, using umask(2) as precedent.
1) Please don't, at least not without much more thought.
2) Doing umask(2) that way was perhaps a mistake.

Let me shed some light on the history of these things, first recalling
some philosophy that UNIXers are supposed to hold dear:

Nothing goes in the kernel unless it MUST.
Don't add system calls unless you MUST.
Don't add per-process state, unless:
	a) The kernel needs convenient/efficient access to it.
	OR
	b) It must be there for protection.

Way back, PWB/UNIX added 3 per-process data items, which were given
shell variable names.  This was done only after great agonizing.
PWB also changed file creation modes (manually) everywhere to
avoid creating 0666 files; this was not elegant.

It was absolutely clear that it was NOT a good idea to keep adding
piecemeal data items to the u-area to cover every single thing
that people wanted, adding new system calls to get/set each value.
By this time [1977], there were all sorts of (different) extra such
goodies tucked away in different UNIX variants, and this was not good.

Hence, the environment feature was designed into V7 as a general
mechanism to cover all miscellaneous data, such that:
	a) the kernel never needed to access the data items directly.
	b) Users who wanted big environments could pay for them,
	without penalizing everybody by making the u_area qutie large,
	or by having extra storage mechanisms.  Note: when this was
	done, it was noted that there was "the possibility for untasteful
	expansion of the enviroonment", and this has indeed come to pass,
	as one sees multi-KB-size environments floating around.
	c) No extra system calls were needed.
	d) No protection mechanisms were needed or desired [we designed
	a horde of variants that had the environment as a kernel-protected
	list of name-value-protection tuples; every single one of them
	was ugly, expensive, incomprehensible, or a combination.]
	e) System call interface routines could, as needed, interrogate
	environment variables as needed to provide useful behavior;
	these was deemed greatly preferable to having the variable
	knowledge get wired into the kernel.  [example execvp & friends].
	This was especially true when the semantics might want to change,
	as was the case in figuring out how to use $TERM early on.

In some sense, doing umask the way we did was a mistake, since the user
can change it at will, and it could have been implemented via an environment
variable, with appropriate changes to creat.  If I had it to do over,
I'd be strongly tempted to do it this way, although it adds code to
creat(), and the reasonably efficient code wants
to look at the environment once, and cache the initial value.
This has some funny semantics, but could probably be tolerated.
In any case, umask seemed simple enough, and people were, as I recall,
generally thinking that it was tied closely enough to file protection that
it was worthwhile, so it was put in this way.

In summary, I again plead with people to seek solutions that avoid 
piecewise additions of u_area state and system calls.  If something
important cannot be done any other way, there is good justification
for doing it.  Otherwise, one is just adding to the overgrowth in there,
rather than helping keep it pruned.

[ I always thought that umask should have been per-directory, not per-process.
In 4.2BSD the group of a new file is that of its parent directory.  If umask
worked similarly, I wouldn't have to be always reminding people to use umask
before working on sources.  -mod ]

Volume-Number: Volume 5, Number 22