From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin C.Atkins To: 9fans@cse.psu.edu, inferno@topica.com Message-Id: <20030224204958.157fccfe.martin@mca-ltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [9fans] A proposal regarding # in bind Date: Mon, 24 Feb 2003 20:49:58 +0530 Topicbox-Message-UUID: 705abdf8-eacb-11e9-9e20-41e7f4b1d025 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