Messages in this thread |  | | Date | Sat, 29 Jun 1996 15:17:01 -0600 (CST) | From | Aaron Ucko <> | Subject | Re: Network performance |
| |
> For those who've never had the privilege of working on an Apollo >system, a variant link is a symbolic link with an embedded environment >variable reference: > > ln -s "/usr/${BINARY_FORMAT}/lib" /usr/lib > >would make /usr/lib a link to either /usr/aout/lib or /usr/elf/lib >depending on the value of the environment variable BINARY_FORMAT at the >time the link is dereferenced. This was used on Apollo systems to support >three operating environments: Domain/OS, BSD4.3 and SYS5.3 all at the same >time. /bin was a variant link depending on the value of SYSTYPE. This was >incredibly useful! One use I can see for it immediately is to have >/usr/src/linux be a link to the source of the currently executing kernel. >Trivial with variant links. Anyone interested in building it?
I've never worked with an Apollo, but I seem to recall seeing variant links on NeXTs over AFS last summer. I'll grant that they're a nice feature, but they're not strictly compatible with normal symlinks; any link to a file with $ in its name would be broken.
> The other feature that was really handy was extended pathnames. This >related to the Apollo's typed filesystem. A filesystem object had a >particular type with an associated type manager (essentially a library to >handle the typical file operations). A type manager could accept additional >filename components beyond the name of the actual file, i.e. a file called >/usr/foo could be openned as /usr/foo/bar. The type manager would be >responsible for doing something meaningful based on the extra components. >One system that used this extensively was the Domain Software Engineering >Environment (DSEE). DSEE provided version control (among other things). A >file under DSEE control could be referred to as: .../library/file to refer >to the latest version of the file or as .../library/file/revision to refer >to a particular revision of the file. This made it really easy to do things >like fetch the versions of all files that were used to build a particular >release, etc.
Interesting concept, but it looks as if it could have a fair amount of overhead.
Come to think of it, both of these ideas should be implementable in userfs, so no kernel changes are strictly necessary.
-- Aaron Ucko (ucko@vax1.rockhurst.edu; finger for PGP public key) | Geek Code 3.1 [for explanation, finger hayden@mankato.msus.edu]: GCS/M/S/C d- s+: a18 C++(+++)>++++ UL++>+++ P++(+++) L+++(++++)>+++++ E- W+(-) N++(+) o+ K- w--- O M-@ V-(--) PS++(+++) PE- Y+ PGP(+) t(+) !5 X-- R(-) tv-@ b++(+++) DI+ D-- G++(+++) e>+++++(*) h!>+ r-(--)>+++ y? | "That's right," he said. "We're philosophers. We think, therefore we am." -- Terry Pratchett, _Small Gods_
|  |