I disagree. Look at SCSI disks, for example. Furthermore, 8 bit
minors artificially mask some of the problems with devfs.
>
> the problem of /dev is different : there is no good management software,
> and the kernel doesn't do much to help manageing it (/proc/devices
> exists, but contains only major numbers and not much information).
>
That is definitely true. My personal opinion is that device drivers
should be bundles of some sort, which should include either the device
nodes or a program to generate them, the kernel module, and possibly
other things necessary.
As far as pty's are concerned, I think it is going to be necessary to
let the kernel create device nodes for them. However, this doesn't
have to be a separate filesystem -- the kernel is perfectly capable of
creating traditional on-disk device nodes, which don't have to reside
in memory and naturally swap out to disk when not needed. The scheme
I imagine is the following:
- The openpty() library function opens /dev/ptx, the master
clone device (did I get the name right)?
- The kernel allocates an unused pty pair, and at the same
time mknod's /dev/pts/NN with the uid and gid of the current
user, unless /dev/pts is setgid, in which case the gid is
gotten from the parent directory (standard creation rules!)
If it is already there, it is unlinked and recreated.
- The openpty() library function does an ioctl() to find out
the pty number; the slave device being /dev/pts/%d.
I'd vote against using a hybrid BSD/SysV naming scheme for pty's,
although we may allow the BSD-ish tty's to remain for compatibility
(probably using a different set of device numbers.)
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables