Re: How limits are enforced (was: various maxproc limits)
Re: How limits are enforced (was: various maxproc limits)
- Subject: Re: How limits are enforced (was: various maxproc limits)
- From: Terry Lambert <email@hidden>
- Date: Thu, 13 Oct 2005 14:37:19 -0700
It's the same for any.
The pty limitation on any UNIX wihtout a cloning pty implementation
comes from two places:
1) the hard-coding of naming conventions into libc routines, e.g.
openpty():
static char line[] = "/dev/ptyXX";
...
for (cp1 = "pqrstuvwxy"; *cp1; cp1++) {
line[8] = *cp1;
for (cp2 = "0123456789abcdef"; *cp2; cp2++) {
line[5] = 'p';
line[9] = *cp2;
if ((master = open(line, O_RDWR, 0)) == -1) {
if (errno == ENOENT)
return (-1); /* out of
ptys */
} else {
i.e.: this example clamps them at 160, based on naming conventions.
If you made more than that, openpty() would still be unable to find
them because of this limitation in its naming convention search
space: it only looks for names in this 10 x 16 namespace.
2) Compile time configuration of the parameter to pty_init.
This value comes from the bsd/conf/MASTER file, in the case of MacOS
X, which generates an initialization stub at compile time that
invokes the init routines for pseudo-devices. In this case, the
configuration line is:
pseudo-device pty 128 init pty_init
which sets the limit at 128.
-
Since we ship the same kernel for both server and desktop, it doesn't
vary.
-
You could potentially hack the value up to as high as 160 by
modifying the parameter to the init routine in the array referenced
by the symbol pseudo_inits by hacking the kernel binary (you can
compare the ->ps_func value to the address of "_pty_init" to find the
right one to hack the ->ps_count on, so you should be safe just
running the table until you find the NULL function pointer that
causes the init loop to exit). This has to be done in the kernel
image, because the pseudo device initialization occurs on the irst
thread started on the BSD side of things -- bsd_init() calls
bsd_autoconf() calls the init routines:
{
struct pseudo_init *pi;
for (pi = pseudo_inits; pi->ps_func; pi++)
(*pi->ps_func) (pi->ps_count);
}
prior even to IOKit startup.
An alternative would be to make a copy of the pty device driver to
either fill out the remaining 32 entries and/or supply a huge number
of entries with your own naming convention, and supply your own
openpty() routine that knows about your new pty driver code.
I've suggested this one before, since you might consider the hack to
160 worth it but dangerous... 8-).
-- Terry
On Oct 13, 2005, at 1:49 PM, Yefim Somin wrote:
Just to clarify: is this limit of 128 pty's the same for any flavor of
MacOSX or does it vary between server and desktop for instance?
Thanks,
Yefim
-----Original Message-----
From: Terry Lambert [mailto:email@hidden]
Sent: Friday, September 30, 2005 3:38 AM
To: Yefim Somin
Cc: email@hidden
Subject: Re: How limits are enforced (was: various maxproc limits)
P.S. While I was writing this, an email from you came in which the
limit on
the number of ptys (128) is mentioned. Could this be the limit I am
running
into, and if yes, can this be bumped?
It shouldn't be, unless one of the other potential problems with the
software being run and listed above is being exercised and keeping
the pty's busy or you are trying for more than ~128 simultaneous
connections. As long as you don't have that many connections, you
will be fine.
Right now, the number of pty's can't be bumped above 128.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden