tdh@frog.UUCP (T. Dave Hudson) (06/13/90)
(I'm not sure where a discussion of the following belongs, and so am not redirecting followups.) I received replies from omerzu@quando.quantum.de andyb@coat.com lamy@cs.utoronto.ca brnstnd@stealth.acf.nyu.edu All of these used different schemes, presumably all of which break would-be-portable code. 1) Nixdorf TARGON/35-50 w/ Pyramid OS Naming convention: /dev/[pt]ty[p-z][0-9a-f] Comments: This only allows for 176 ptys. 2) Sequent, w/ DYNIX Naming convention (ordering of a-z vs. A-Z reflects numbering): /dev/[pt]ty[p-wP-W][0-9a-zA-Z] Allocation convention: int getpseudotty(char **slave, char **master) (returns master r/w FD or -1) Misc: 1) similar scheme starting with ttyx0 for X.25 logins 2) ispseudotty(char *ttyname) (with ttyname stripped of "/dev/" prefix) Comments: This allows for 992 ptys. I also like the idea of encapsulating the allocation of ptys. 3) MIPS and SGI, w/ RISC/os Naming convention (slave only): /dev/ttyqn (n is decimal number) Allocation convention: 1) open /dev/ptc, fstat() it, use minor dev for slave 2) open /dev/ptcm, open /dev/ptcm[0-9] until matching (st_rdev) major device#, multiplying the last digit by 256 and adding the minor dev# for the slave Comments: The first scheme allows for 256 ptys, the latter for 64K-1. I like saving on almost all of pty* device files. It looks like this breaks SVID's utmp.h. 4) Dan Bernstein's pty program Naming convention: /dev/[pt]ty[p-za-o][0-9a-f] (but with PTY1 and PTY2 ranges in Makefile) Allocation convention: Dan is writing a UNIX-domain sockets daemon for allocating pty descriptors, and would re-write for streams. Comments: This allows for at least 416 ptys. Dan claims that under a /dev/[pt]typ<decimal#> scheme "[m]any utilities will die horribly if tty extensions are larger than two characters", but I don't see how any scheme here wouldn't fail to be portable. I like the Sequent/DYNIX allocation convention. The only feature that it lacks is an overall pty index (such as is used by MIPS and SGI), a feature I've seen used here under a dumb-terminal windows program used internally. This lack can be compensated for by using *stat() to get the device#, playing some games to avoid a large index. It is not necessary to accept the Sequent/DYNIX naming convention, since this can be hidden. It looks like it is unnecessary for a pty's name to exceed 10 characters, but the SVID limit in utmp.h is 11 characters anyway, if a character is reserved for a terminating ASCII NUL. In an ideal world, I'd have "int getpseudotty(char *slave)", with "slave" (perhaps pre-filled) a 12 char array to be NUL-terminated, and possibly avoiding the use of a master-side device entirely. There seem to be no widely accepted pty conventions. I'd like to see some discussion before deciding what conventions to use. David Hudson
brnstnd@kramden.acf.nyu.edu (06/13/90)
In article <15618@frog.UUCP> tdh@frog.UUCP (T. Dave Hudson) writes: > I received replies from > omerzu@quando.quantum.de > andyb@coat.com > lamy@cs.utoronto.ca > brnstnd@stealth.acf.nyu.edu > All of these used different schemes, presumably all of which break > would-be-portable code. You can integrate my pty program gradually into your current environment, without changing any old programs. In other words, it doesn't break any portable BSD code. Of course, any new code that uses pty can take advantage of its security, disconnectable sessions, and full efficiency even after a reconnect. As an example, I included in the pty package some patches to the latest telnetd. Under the patched version, any login shell is disconnectable by default. Furthermore, you get the same I/O efficiency as the pre-patched telnetd. And all this is practically invisible to the users. [ Sequent/DYNIX pty naming convention ] > Comments: > This allows for 992 ptys. I also like the idea of > encapsulating the allocation of ptys. I also like modularity, to the extent that pty is an entirely separate program that you can easily reconfigure without recompiling any other code. You can also use it in shell (or perl) scripts, or from the command line (remember the ``condom'' discussion not long ago?). One of the biggest advantages of this system is pty security, which you simply can't achieve any other way. (Witness Sun's idiotic mode 666 /etc/utmp.) Note that pty provides full support for programs that need direct control over the master side of the terminal. The latest telnetd, for example, supports Linemode; even though it lets pty do all the pseudo-terminal allocation in a separate process, it retains the control necessary to pass terminal ioctls through the network. > 4) Dan Bernstein's pty program > Naming convention: > /dev/[pt]ty[p-za-o][0-9a-f] > (but with PTY1 and PTY2 ranges in Makefile) > Allocation convention: > Dan is writing a UNIX-domain sockets daemon for > allocating pty descriptors, and would re-write for > streams. Ummm, those are just future internals for better support of more modern systems. Right now the code should be easily portable to any BSD 4.2 or 4.3 system. Anyway, the *interface* is what matters: to run program foo under a pseudo-terminal session, you just run pty foo. > Comments: > This allows for at least 416 ptys. Dan claims that > under a /dev/[pt]typ<decimal#> scheme "[m]any > utilities will die horribly if tty extensions are > larger than two characters", but I don't see how any > scheme here wouldn't fail to be portable. Hmm? Although I include public-domain clones of various utilities in the pty package (including a script that *works*, can be suspended, uses /etc/utmp correctly, etc.), pty supports the same old BSD convention of /dev/ptyxx. So old accounting programs that read utmp or wtmp don't have any problem working with pty. That ``scheme'' sure is portable. Anyway, /dev/pty[a-zA-Z0-9][a-zA-Z0-9] gives you nearly four thousand ptys to play with (provided you configure them all into your system). You change one line in pty's Makefile to support this. Note that pty has an option for searching through ptys randomly, so it won't get slower and slower and slower like most pty-allocating programs. > There seem to be no widely accepted pty conventions. I'd like to see > some discussion before deciding what conventions to use. I recommend not using a particular convention at all. Assume that there is another program, ``pty,'' with a reasonably standardized interface. Just stop worrying about the internals. Oh, yeah, the current pty submission to c.s.unix is available upon request or via anonymous ftp to the new archives at stealth.acf.nyu.edu (128.122.128.22). pub/pty.3.0.shar. ---Dan