[9fans] A proposal regarding # in bind

[Martin C.Atkins <martin@mca-ltd.com>]

Hi,
	One thing I have never quite felt comfortable with in Plan9
and Inferno, is the special treatment of '#' in the bind system call,
and more generally, at the start of any path given to open, etc.
(The following discussion uses Inferno examples, but most have direct
Plan9 equivalents. I've cross-posted this to both groups, since it is
a question about both systems - I hope that is OK!)

Problems I see with '#' include:
It is a special case:
	Nowhere else is there a similar mechanism/convention.

Limited:
	What happens when we run out of letters/glyphs to represent devices?
	(Ok, so there *are* 65,000-odd glyphs... :-)

Awkward:
	Many device letters are no-longer obvious. E.g. Many devices could
	reasonably be #s - SCSI, serial, etc. Oops, no it's srv!
	Is #d a disk, or /dev/draw?
	Why is flash '#W'? Why is ssl '#D'? (Because '#s' is srv perhaps?)

Breaks the rules in 'The Hideous Name':
	why can't I do:
		ls -l #?
	to see all the devices, etc...

Requires other special cases:
	Such as the sys-pctl option, NODEVS.

I think I have a proposal that could replace this mechanism, addressing all
these problems, while providing a (reasonably) clean backwards compatibility option
until the rest of the system caught up.

I propose a special filesystem driver, call it 'proto', which is mounted
on /proto by the kernel, during the creation of the first, 'init', process
from which all the others are derived by forking.
The /proto directory would contain a file for each device, so that instead
of
	bind '#c' ...
one would do
	bind '/proto/console' ...
(or "bind '/proto/cons' ...", if you must insist :-)

The special behaviour of proto, would be that attempts to bind files within
it would do what binds of names beginning with '#' currently do.

Then one could:
	ls -l /proto
to see the devices on this system.

But lots of programs have "#..." filenames in them, so what about them?
While such programs continue to exist, system calls would be changed so that '#x'
at the start of a filename would be expanded to:
	/proto/shortnames/x
The "shortnames" directory would contain the single letter pseudonyms for the drivers.
Furthermore, "bind '#Dppp/path' ..." would be rewritten to:
	bind '/proto/shortnames/D/ppp/path' ...

So that the example from KFS(3):
	echo filsys fs kfs.file >'#Kcons/kfsctl'
would be equivalent to:
	echo filsys fs kfs.file >'/proto/shortnames/K/cons/kfsctl'
or, to:
	echo filsys fs kfs.file >'/proto/kfs/cons/kfsctl'

(
	bind '#D/path' ...
could map to:
	bind '/proto/shortnames/D/./path' ...
or are there any better suggestions? Would
	bind '/proto/shortnames/D//path' ...
actually be safe enough?)

Once drivers are represented by files, lots of other things become possible
(although some of these might be going too far...)

Access to devices could be controlled by permissions, etc.

One could have a /proto/ctl file to which commands could be sent to remove
(or even add?!) devices from the visibility of this, and inheriting, processes
(a sort of fine-grained NODEVS).

"sys->pctl(NODEVS, [])" itself could be replaced by:
	unmount /proto
since there is no way for a program to name the proto driver, there is
then no way to get access to it once it has been unmounted, or to gain
access to any other devices! '#' names would expand into non-existent paths.

This all seems so obvious, that I can't understand why it hasn't always
been done this way!

I'm sure that there would be many practical issues to sort out in
changing to this kind of scheme. One problem that springs to mind is
the format of /prog/pid/ns, and programs that read it...

But are there any fundamental problems with this approach? Was there some
clever reason why this wasn't done from the start, or would cause untold
problems that I haven't thought of?

I.e. Am I missing something, or is it a 'good idea' (that might be
too much trouble to change for now)?

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com