gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/09/88)
In article <1023@murtoa.cs.mu.oz.au> kre@cs.mu.oz.au (Robert Elz) writes: >yes, what's more maybe we could do away with major *numbers* completely >and use major *names* instead. Better yet, have /dev be a special file system of its own (using the file system switch) that takes care of the details of mapping strings to driver entries. I suggested this to DMR some time ago but don't know if anyone followed up on it.
guy@auspex.UUCP (Guy Harris) (11/12/88)
>Better yet, have /dev be a special file system of its own (using the >file system switch) that takes care of the details of mapping strings >to driver entries. One nuisance with this would be that, unless the contents of this file system were somehow recorded (completely or partially) in some form of non-volatile storage, you'd have to stick bunches of "chown" commands in some place such as "/etc/rc" in order to be able to administer permissions on files. The simplest implementation of such a file system would give all "/dev" files the same permissions, and that would either be too restrictive or too permissive a default; fancier implementations would quite likely put policy code into the kernel, which I would oppose both for philosophical and practical reasons. I don't have any great problem with the "chown"s being stuck in "/etc/rc" (the moral equivalent of those "chown"s are in "/dev/MAKEDEV" on BSD systems and systems that have adopted MAKEDEV from BSD, for example), but it may be a minor inconvenience to have to stick them there.
guy@auspex.UUCP (Guy Harris) (11/12/88)
(Continued from previous rock) Some people at Sun have suggested the same idea, with "specfs" becoming not just a class of vnodes but a "real" mountable file system. Bill Shannon suggested making "/dev/fd" a file system; this has the advantages that 1) you might not have to whack up the VFS kernel's "open" code to pass an extra argument to device drivers (as in Arnold Robbins' "/dev/fd" driver); 2) you would't have to create or destroy entries based on the maximum number of file descriptors per process supported by your kernel. (You could even get *truly* perverse and have it look different in different processes, so that it reflects the number of *open* file descriptors....)