lkml.org 
[lkml]   [1996]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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_


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.108 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site