[58] in DCNS Development
Re: Filesystem Reorganization for release 7.3
daemon@ATHENA.MIT.EDU (Richard Basch)
Mon Jul 8 15:17:22 1991
Date: Mon, 8 Jul 91 15:14:31 -0400
To: "Jonathan I. Kamens" <jik@cats.UCSC.EDU>
Cc: developers@MIT.EDU, release-73@MIT.EDU, acmg@MIT.EDU, bug-sipb@MIT.EDU,
In-Reply-To: Jonathan I. Kamens's message of Mon, 8 Jul 91 11:29:32 -0700,
From: Richard Basch <basch@MIT.EDU>
Keep in mind the "backward compatibility" argument and deferring the
removal on the existing platforms does not provide reason to create the
link on NEW platforms. The issue comes down to one of layering Athena.
We are trying to minimize the hooks, and as you said, the software
should not be considered Athena; this implies that it is not Athena's
responsibility to provide the hooks SIPB uses for its overlays.
This is a bit stronger than what my real opinion is, but I would like to
see us avoiding extra modifications to the vendor's products, if
possible. The new architectures require:
{/bin,/etc,/usr}/athena
and a couple of files modified (ie. login) to tie the base operating
system into the Athena environment. [/mit was intentionally left out as
attach can create the hierarchy, and will destroy it when it is done].
Of course, we could change the mountpoint to: /usr/sipb. On existing
platforms where /usr/sipb->/mit/sipb, attach will follow the symlink and
not have a problem. A common restriction is to prohibit mounts on /usr,
and on new platforms, if the link does not exist, you will not be able
to attach "sipb" on these more restrictive machines.
-Richard
