dce@mips.COM (David Elliott) (06/13/88)
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.
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcehaahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr) (06/14/88)
In article <2371@quacky.mips.COM> dce@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@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@princeton.edu
guy@gorodish.Sun.COM (Guy Harris) (06/15/88)
> (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). Blame where blame is due :-); the "look at $PATH" hack was originally conceived by, I believe, Dave Korn (at least I got the idea from some mail I received from dpk).
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/15/88)
In article <56555@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> (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). >Blame where blame is due :-); the "look at $PATH" hack was originally conceived >by, I believe, Dave Korn (at least I got the idea from some mail I received >from dpk). DPK or DGK? What I have suggested is that ALL echo commands be given both -n support (for V7/BSD compatibility) and -e support a la V8/V9. That would provide a migration path for shell scripts and allow reasonable default behavior for some future merged version of "echo" instead of escape mapping a la SysV.
aglew%fang@xenurus.gould.com (Andy Glew) (06/16/88)
..> The namei hack - variable substitution in filenames or
..> symlinks.
If you are willing to restrict yourself to very heavyweight
environments, eg. BSD/SV system wide rather than each user
individually, then you can get the same effect using symlinks,
boxes, and something like an NFS self mount.
Eg. create a single filesystem with all the important directories
like /bin symlinks to /ENVIRONMENT/bin, for example.
Create two environments, /sv containing /sv/ENVIRONMENT
and /bsd...
NFS mount onto your own machine all the files and filesystems
that would be below /, to beneath /sv and /bsd.
Finally, chroot (with all appropriate caveats) to /sv or /bsd
depending on which environment the user wanted to live in.
Ain't it horrible?
Don't worry, we don't do anything like that.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have MX records
aglew@xenurus.gould.com - if you don't
...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.rbj@ICST-CMR.ARPA (Root Boy Jim) (06/16/88)
? From: David Elliott <dce@mips.com>
? 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.
Sequent and Pyramid have `conditional symbolic links'. While not as
general as the scheme you describe, they look like:
2 lrwxr-xr-x 1 root wheel 4 Jan 11 16:10 /bin -> ucb=.bin att=/usr/att/bin
and are made like:
LN(1) DYNIX Programmer's Manual LN(1)
NAME
ln - make links
SYNOPSIS
ln [ -s ] name1 [ name2 ]
ln [ -s ] name ... directory
ln [ -f ] name ... directory
ln -c att=name1 ucb=name2 name3
DESCRIPTION
...
The -c option causes ln to create symbolic links. The
values for the conditional symbolic link must be given,
preceded by the corresponding universe identifier (`att=' or
`ucb='). The values may be given in either order.
Hope this helps. I see no reason why the names should be restricted to
`ucb' and `att'. Of course then wd'd need a `default=' clause or return
an untranslatable error or use the first as a default.
? David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
My name is in /usr/dict/words. Is yours?greg@vertical.oz (Greg Bond) (06/16/88)
In article <2371@quacky.mips.COM> dce@mips.COM (David Elliott) writes: >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". What do you mean by a variable? How can such variables be set up so that the kernel context can access them? Not shell variables, obviously (as the process doing the system call is not in general a shell), but even "environment" variables can be changed by the process and I can't see how namei would know where to look for them. A question from the curious but not source-equipped mind of... -- Gregory Bond, Vertical Software, Melbourne, Australia Internet: greg@vertical.oz.au (or greg%vertical.oz.au@uunet.uu.net) Bang: {uunet,mcvax,pyramid,mnetor,ukc,ucb-vision,...}!munnari!vertical.oz!greg I used to be a pessimist. Now I'm a realist.
dce@mips.COM (David Elliott) (06/18/88)
In article <126@vertical.oz> greg@vertical.oz (Greg Bond) writes: >In article <2371@quacky.mips.COM> dce@mips.COM (David Elliott) writes: >>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". > >What do you mean by a variable? How can such variables be set up so >that the kernel context can access them? Not shell variables, >obviously (as the process doing the system call is not in general a >shell), but even "environment" variables can be changed by the process >and I can't see how namei would know where to look for them. It really doesn't matter what kind of variable. Even the Pyramid "universe" is a kind of variable; it's just restricted to two values. My original description is quite restrictive, as it states that it allows people to choose default execution "universes". With this restriction, it's quite easy to set it up so that the value of the variable gets passed to the kernel. The system call wrapper could simply decode the current value of an environment variable and pass it to the kernel. A variation of this is to have the system call interface send the environment pointer to the kernel. You can send pointers to other types of objects, why not the environment? Another option is to say that the "variable" is set by a system call, as the umask or the nice value is. Obviously, the first two methods can cost extra time, so care must be taken to understand how to do it. The thing to remember is that we (meaning the company developing the system) owns the system call interface, so we can modify it as needed. -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce