From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9
From: anothy@cosym.net
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20011105181824.B51E4199B5@mail.cse.psu.edu>
Date: Mon,  5 Nov 2001 13:18:21 -0500
Topicbox-Message-UUID: 14c8a276-eaca-11e9-9e20-41e7f4b1d025

// 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.

first off, take a look at /lib/namespace (what i think you're getting at in
the second item in your list) and the namespace operations in
/usr/<user>/lib/profile (the third in your list, i think). bind, mount,
unmount, etc. in both places. same for the user. at the system level, it
all goes down into calls to things in bind(2). same system mechanics
regardless.

you _tell_ the kernel where to get its root file system (the first thing it
mounts) from at the "root is from" prompt on booting. there's nothing
special about "creating links" going on when you import a fs that
happens to be living on disk. the tools for manipulating "links" are not
different depending on whether we're dealing with disk or not. try:
	cd /env ; echo bark > tree ; mv tree wood ; cat wood
and lemme know what you get. no disk structures. same in ramfs and
other places.

// 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.

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.
ア