Messages in this thread |  | | Date | Sat, 29 Jun 1996 16:18:02 -0600 (CST) | From | Aaron Ucko <> | Subject | Re: Network performance |
| |
> 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. > >I used to work quite a bit with Apollo's and Domain/OS, and I still miss some >of its features. I also found the variant links to be especially useful. The >only case that was treated specially was $(VAR) in a name; if the $ did not >include the matching (VAR) then it did not have special meaning. I don't think >you'll find very many uses of $(VAR) in symlinks; it's a worthwhile trade-off, >in my view.
Perhaps it is, but if symlinks are specified by POSIX (and I think they are) than variant symlinks are non-POSIX by that technicality.
>[discussion of type managers omitted] > > Interesting concept, but it looks as if it could have a fair amount of > overhead. > >Not really.
Oh? Either they'd be built into the kernel and make it larger (which I seriously doubt Linus would endorse) or they would have to run in userspace and be launched whenever a "virtual" file was accessed, which would have non-negligible overhead AFAIK, so in that case one might as well go whole hog with userfs wrt this and not add to kernel code.
> Come to think of it, both of these ideas should be implementable in userfs, > so no kernel changes are strictly necessary. > >There was relatively little or no kernel support for this on the Apollo either. >The kernel itself had no notion of read/write for disk files. All disk I/O was >done through memory mapping and then reading/writing the memory. This includes >access to files anywhere in the network, since demand paging of virtual memory >mapped from any object in the network was implemented at the heart of the OS. >You could boot a node to the equivalent of single user mode and then peruse and >manipulate its file system from another node. > >Domain/OS used shared global libraries to provide the user visible >functionality that was not part of the kernel itself. All the normal file >operations went through the global library, which either directed them through >the inherited default I/O Switch operations or to operations provided in an >installed type manager library.
Interesting...how was this made secure? The OS must have implemented shared libs in such a way that library code was privileged but user code wasn't... I don't even want to THINK about statically linked binaries! :-) Reminds me of Hurd, though.
>By the way, Atria is the inheritor of Apollo's DSEE technology. In normal Unix >systems, the special functionality that the typed file system provided is now >mimicked by using an NFS server for accessing the data. It is free to perform >the special interpretation of file names that the type managers in Domain/OS >performed.
Loopback NFS is just another way to implement userfs, so my comment about this not being a kernel issue still applies. It IS an interesting idea, though.
-- 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_
|  |