On Sun, 10 Sep 2000, Jaromír Doleček wrote:

: Following the David's advice and after more though, I'm working
: on making the kern.maxptys value settable to any value bigger
: than current number of ptys. 

We really need to consider implementing SVR4's ptm(4) as a regular device.  
The historic BSD hunt-group pty convention, while simpler in kernel code, is
just not scalable.  If 512 ptys are allocated, that means an application
will need to attempt to open(2) 513 device nodes before a success!

The way ptmx(4) works is that the master side opens /dev/ptmx, obtaining the
equivalent of a /dev/pty* master side.  There is a trick here, though:  a
stat(2) on the acquired file descriptor returns a st_rdev that contains a
minor device number corresponding to the slave side's unit number (instead
of the minor device number of /dev/ptmx).  That unit (also the minor number
of the slave side device) is found at /dev/pts/X.

Now... ptmx *can* overlap the /dev/[pt]tyXX set, or it can be an addition to
them.  Solaris, for instance, implemented ptmx as its own set of ttys, with
the /dev/[pt]tyXX set as a fixed-size separate chunk.  The important
programs--login, sshd, ftpd--have ptmx support there, while third-party
tools using BSDisms could still find free ptys using the BSD scheme.

As long as ttyname(3) understands the /dev/pts/* nodes properly, most
programs should have no problem understanding the new nodes.  The only ones
that may have problems are statically linked binaries depending on tty
pathnames, which shouldn't be too many.

[You'll note that src/sys/compat/svr4/svr4_net.c:svr4_ptm_alloc() provides a
compatibility version of /dev/ptmx that contains the ugly BSD hunt code.]

See the following URL for the relevant Solaris manpage; you can ignore the
STREAMSisms there (the references to M_* messages).

    http://man.cs.wisc.edu/cgi-bin/man?OS=sun&command=ptm

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.