On Tue, 2010-01-12 at 09:34 -0500, Mario Charest wrote:
> > >  Any way to get over the 176 ptys limit?
> > 
> > The limit corresponds to UNIX pseudo-terminal naming conventions, ie ttyp0 ...
> >  ttyzf (11 * 16 == 176).  libc functions such as posix_openpt(), or utilities 
> > like telnetd which implement their own scan, and others, 'know' of this 
> > convention when looking for the next pty to use.  So more ptys would possibly 
> > be unusable.
> > 
> > Although some digging around seems to indicate that many newer utilities (
> > including latest telnetd and qconn) use a more recent convention which 
> > continues cycling with PQRST, which would then result in (16 * 16) 256 pairs.
> > 
> > So it could be that the limit enforced by devc-pty is old / too restrictive, 
> > and could continue from 'ttyzf' to 'ttyP0' etc.  I'll raise a PR to try and 
> > get some consistency here, or investigate if there's another limit (eg minor 
> > devnos).
> > 
> > Currently this is a hard-coded limit in devc-pty (due partly to its 
> > algorithmic construction of names).
> 
> 
> Thanks for the info. I read the doc which was mentioning the UNIX
> naming conventions but then though about these UNIX boxes that can
> handle thousands of telnet session ;)

IIRC they use the newer /dev/pts/nnn convention; I'm not too sure what
the limiting factor is then, but possibly minor device numbers.

Regards,
Neil

> Thanks for the info. I read the doc which was mentioning the UNIX naming 
> conventions but then though about these UNIX boxes that can handle thousands 
> of telnet session ;)

They would be using the alternative UNIX98 pty conventions, with a pty multiplexor entry point, and the openpt/granpt/
unlockpt/ptsname API.

The BSD scheme wouldn't scale so well due to the name scan (even if you came up with cycling lots of char suffixes).  
Also our current implementation allocates all IO buffers and names up-front, at the max specified.

For now I've changed devc-pty to allow 256, in the pattern expected by our telnetd.

Going forward, probably a switch to UNIX98 is required, with a new devc-pty, although client software could be phased by
 running both old and new pty drivers to provide both APIs.  Please contact your customer service rep if this is 
something you would require on the product roadmap.