From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
Message-ID: <87ady04hw2.fsf@becket.becket.net>
Content-Type: text/plain; charset=us-ascii
References: <20011105181824.B51E4199B5@mail.cse.psu.edu>
Subject: Re: [9fans] Plan 9
Date: Tue,  6 Nov 2001 10:32:35 +0000
Topicbox-Message-UUID: 15c8de70-eaca-11e9-9e20-41e7f4b1d025

anothy@cosym.net writes:

> // So in that case, in Plan 9 there are at least four different sets of
> // tools for making a new link--at least.  Some sample places that links
> // get specified:
> //
> //   * Default links go in the fileserver's data structures on disk, and
> //     are manipulated by a host of cooperating programs and syscalls.
> //   * Other defaults go in the file that specifies the initial contents
> //     of users' mount tables.
> //   * Users have startup files that fill their mount tables with links.
> //   * Shell commands and syscalls are available to change the mount
> //     tables transiently.
>
> i think you're confused, and i think it's because the idea of "links" from
> the Unix world doesn't really translate well into the Plan 9 world.

By "link" I mean specifically what it is that gets followed in a
directory when a name is looked up.  That might be in a mount table or
on a filesystem, and I'm counting up the places where one might
specify "I want a link to exist here".

The various wrappers around bind(2) certainly all boil down to the
same thing.  So let's pretend they are all one thing, and we still
have two different kinds of links: those made by bind(2) and those
made by link(2).

This is a matter of an implementation difference being exported to
users.  One consequence of it is that there is a performance penalty
on users who might want very large mount tables.

> maybe i just totally miss what you're getting at (as you warned we
> might). but the above point is kinda fundamental to Plan 9. of _course_
> structures on disk is just an implementation. when my terminal boots
> up, it doesn't know - nor care - where the files being served to it come
> from, or how they're stored. local or remote disk, tape, ram, kernel
> devices, optical jukeboxes, CDs, whatever. same protocol talks to them
> all, same tools manipulate them all, and to the system they're more or
> less indistinguishable. that's the point.

I was being sloppy.  Instead of "on disk" I should have meant
"accessible by the file protocol" (whatever kind of file it is).

Some links are found by asking a file server; some are found by
consulting the process's name space.

I'm not suggesting a change in Plan 9; I'm thinking about file system
name spaces in general, and thinking that the per-process variability
of Plan 9 is great, but I think it could be taken even further; in
that way unifying all the different kinds of links there are.