Magic symlink syntax

[Paul Gluckauf Haahr]

In article <2371 at quacky.mips.COM> dce at mips.COM (David Elliott) writes:
> We are in the process of considering a system modification that systems
> folks lovingly refer to as the "nami hack" (or "namei hack" for BSD folks).
> This is the modification that allows one to put a variable inside of
> a symbolic link target so that people can choose default execution
> "universes" or "modes" or "system types".
> 
> I believe that the Apollo Domain/IX syntax was '($name)' or '$(name)'.
> I'd like to get a list of those currently available, as well as the
> pros and cons of each syntax.
> 
> Also, if other people have come up with functionally similar systems
> that use a different mechanism, I'd like to hear about those as well.

i really don't think that this is a good idea.  you suggest using
variables (presumably from the environment).  pyramid (and others
following their lead, i.e. sequent) have done a "conditional symbolic
link" (like a symbolic link, maps to two (or more?) different names
depending on an entry in the proc structure or u area).  both approaches
are pretty awful.  i would assume you're trying to do this to provide
compatibility with different "standard" unix namespaces.

[ out of curiosity, is this to solve a problem of the past, system v
versus berkeley, or the future, at&t/sun versus osf? ]

the pyramid approach, adding a universe switch to the process state
has real problems in a networked environment, if the network protocol
does not understand the notion of conditional symlinks, which neither
NFS nor RFS do.  how does a client tell a server which universe to use
for network accesses?  do you break the protocol and add a universe
parameter to each NFS lookup request or adding a new incompatible
file type so that the client handles it?  do you specify the universe
when you export or mount the filesystem, thereby losing the advantage
of having per-user universes in the first place.

the approach you suggest is a little better, because you don't need to
add a new file type to do it, at least with NFS, since symbolic link
interpretation is always done by the client side in NFS.  however, what
if the client does not understand having a variable in a link name?  for
right now, it will look up a filename that contains '$', '(', ')', or
whatever characters.

another namespace issue is: are variable evaluated in all pathnames or
just symbolic links?  you can create a file with a variable name in
it, you just can't make a symlink to it?, as in (':; ' is my prompt)

	:; FOO=x
	:; export FOO
	:; > '$(FOO)'		# should this create file x?
	:; ln -s '$(FOO)' y
	:; > y			# this should be file x

or should we go whole hog and say that it isn't symbolic links which
need to know about the environment, but all pathnames?  this would
probably be easier to implement.

moreover, right now the kernel imposes almost no structure on the
environment.  the NAME=VALUE usage is a user-level convention.  to add
pathname variables would impose a kernel interpretation on something
that it didn't have to care about before.  plus, do you really want to
search through the (possibly large) environment every time you use a
file in /usr/bin or wherever?

while it may make porting harder for some rare cases (and probably not
much even there), i would argue that sun's approach taken in SunOS 3.2
(before the controversial SysVr4 agreement on a unified unix) of
merging the universes and providing an alternate directory to put in
one's $PATH is a far better way to go than adding funny stuff to
symbolic links.  (though they came up with one of the ugliest kludges
i've ever seen to handle v7 echo or system V echo as a shell builtin).

rob pike has suggested a more reasonable approach for a customizable
namespace, based on per-process (or per-process group), inherited,
non-scess group), inherited, non-superuser mount tables, that let one
graft part of a filesystem at another location.  (you want system v,
sure, do a "mount /usr.systemV /usr" in your .profile).  if the mount
table is inherited, my choosing one won't make the choice fover a
network, if the client can do such mounts, and it doesn't really matter
what the host does then.  it just has to export a hierarchical file
system.

symbolic links are already pretty hackish.  see dce at mips.com's other
current article (on symbolic links and networks) for just one reason,
and of course there is the whole debate about what .. following a
symbolic link means.  the environment is pretty hackish (it's yet
another namespace, and degrades the performance of exec if it gets too
large).  we're probably stuck with both of them.  let's not make the
existing situation worse.

paul haahr
princeton!haahr or haahr at princeton.edu