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: <87y9lpuih4.fsf@becket.becket.net>
Content-Type: text/plain; charset=us-ascii
References: <20011102135323.938F819A04@mail.cse.psu.edu>
Subject: Re: [9fans] Plan 9
Date: Mon,  5 Nov 2001 10:20:38 +0000
Topicbox-Message-UUID: 13fe3b80-eaca-11e9-9e20-41e7f4b1d025

rob@plan9.bell-labs.com (rob pike) writes:

> Any 'link' can be per-process in Plan 9, but in practice only those ones
> that need to be are invested with the trouble to make them so. Otherwise,
> I would have to write down somewhere what all the default links would
> be for a process when it starts running, and that would be a huge
> list of information and also unpredictable since I can't say what resources
> the process is likely to need dynamically.

Right, that's what I meant by "leave aside implementation for the
moment". :)  I understand why it might be challenging to do it
efficiently.

> In other words, in Plan 9 all links *can* be per-process but only those
> that *need* to be actually are.  Why do it differently?
>
> Or perhaps I don't understand what you're asking.

In a logical sense then, every link *is* per-process.  (Because if it
can be, then in a very real sense, it already is, even if all
processes happen to agree about it.)

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.

Now by far the easiest is the first (if only because there are so many
tools to manipulate such links).

(If you wonder what I'm asking, it's because I'm trying to home in on
a concept, not that I already have it full developed.)

So perhaps part of the issue is a unification of the different kinds
of links, and a reduction in the number of tools and places that all
manipulate and store information about what links there are.

There are two things about links that seem important:

  * Is the link shared between processes/users, and how?
  * Is the link transient or permanent?

You are certainly correct that most links will be shared among most
users; having on-disk data structures that represent them is a
perfectly decent implementation strategy, but now I hope it's clear
that this is just an implementation detail, and need not directly
influence the appearance of the system to the user.

Thomas