Re: How to enable more than 256 pty's?
On 2007-10-02 15:41, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Sm?rgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. There was an old bug, which caused pts consumers to get stuck in devdrn. This has been fixed, AFAICT, a long time ago. At least, I can't reproduce it any more with the usual tests: * Closing xterm windows. * Closing telnet sessions. * Exiting from screen(1) windows. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/4/07, Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2007-10-02 15:41, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Sm?rgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. There was an old bug, which caused pts consumers to get stuck in devdrn. This has been fixed, AFAICT, a long time ago. At least, I can't reproduce it any more with the usual tests: * Closing xterm windows. * Closing telnet sessions. * Exiting from screen(1) windows. Weird. 3 people on this thread already saw the symptoms :( -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 2007-10-04 18:05, Vlad GALU [EMAIL PROTECTED] wrote:
On 10/4/07, Giorgos Keramidas [EMAIL PROTECTED] wrote:
On 2007-10-02 15:41, Vlad GALU [EMAIL PROTECTED] wrote:
On 10/2/07, Dag-Erling Sm?rgrav [EMAIL PROTECTED] wrote:
Vlad GALU [EMAIL PROTECTED] writes:
The symptoms were exhibited even with rev. 1.16. I've CC'ed him so
he can catch up with the thread.
Which symptoms? I can no longer reproduce the hang-on-close bug.
Strangely enough, me neither. In his case, allocated pts' wouldn't
get deallocated once the sessions ended.
There was an old bug, which caused pts consumers to get stuck in
devdrn. This has been fixed, AFAICT, a long time ago. At least, I
can't reproduce it any more with the usual tests:
* Closing xterm windows.
* Closing telnet sessions.
* Exiting from screen(1) windows.
Weird. 3 people on this thread already saw the symptoms :(
It must be a different problem, then. I used to have a local patch
which reverted the devdrn wait in kern_conf.c:destroy_devl() near
the lines:
753 while (dev-si_threadcount != 0) {
754 /* Use unique dummy wait ident */
755 msleep(csw, devmtx, PRIBIO, devdrn, hz / 10);
756 }
but the original problem I was seeing seems to have been fixed.
At least, I can't reproduce it was easily anymore...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Steven Hartland [EMAIL PROTECTED] writes: Thanks for the tip there but I cant find any function called pty_create_slave in the source. Just grep your source tree for occurrences of pqrsPQRS. Is this something that's possible on 5.x / 6.2 or something that will need a lot of work? It shouldn't be any harder on 5.x / 6.x than on 7.x. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Any one got any pointers on this, the machine we running this app on is over 90% idle so I really don't want to have to install a second machine just to workaround a limit on the number of pty's, surely there's a way to increase this? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Steven Hartland [EMAIL PROTECTED] writes:
Any one got any pointers on this, the machine we running this app on is over
90% idle so I really don't want to have to install a second machine just to
workaround a limit on the number of pty's, surely there's a way to increase
this?
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = pqrsPQRS;
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = pqrsPQRS; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr(pqrsPQRS,
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = pqrsPQRS; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 pqrsPQRS
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On Tue, Oct 02, 2007 at 02:05:03PM +0200, Dag-Erling Smørgrav wrote:
Steven Hartland [EMAIL PROTECTED] writes:
Any one got any pointers on this, the machine we running this app on is over
90% idle so I really don't want to have to install a second machine just to
workaround a limit on the number of pty's, surely there's a way to increase
this?
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = pqrsPQRS;
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = pqrsPQRS; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr(pqrsPQRS,
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = pqrsPQRS; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 pqrsPQRS
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
This last option is only available if you are running 7-CURRENT though.
The pts code is not in 6-STABLE (or older.)
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Alternatively, set kern.pts.enable to 1, and find and fix the hang-on-close bug in the pts code (if it hasn't been fixed already) Looks like it hasn't been. A friend who tried to set up an access server for his company stumbled upon it. kib@ says it has as of sys/kern/tty_pts.c rev 1.15 (2007-07-03). Has your friend tried with a sufficiently recent kernel? I can't tell for sure, he tried a week or two ago, with a recent snapshot. I forwarded him your mail, I hope he'll retry and get back to me. The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Steven Hartland [EMAIL PROTECTED] writes:
Any one got any pointers on this, the machine we running this app on is over
90% idle so I really don't want to have to install a second machine just to
workaround a limit on the number of pty's, surely there's a way to increase
this?
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = pqrsPQRS;
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = pqrsPQRS; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr(pqrsPQRS,
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = pqrsPQRS; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 pqrsPQRS
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
Looks like it hasn't been. A friend who tried to set up an access
server for his company stumbled upon it.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. Wouldn't get deallocated right away, or wouldn't get deallocated at all? Apparently, it is not unusual for pts reclamation to be delayed a bit by a non-zero refcnt. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
On 10/2/07, Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. However, I see that, if I use pts/0-7, for instance, then log off pts/7, the next assigned pts will be pts/8. Is this expected? I tried lowering kern.pts.max to 20. If I open 20 of them and close them afterwards, on the next try I get no more ptys from my screen. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
* Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. This is a known issue IIRC. See line 245 of tty_pts.c 1.16. Can be easily reproduced by killing the sshd while apps are still running in the shell. I thought we weren't able to destroy the device there, because you can't destroy a TTY when it is used by an application (i.e. when it's the controlling terminal). -- Ed Schouten [EMAIL PROTECTED] WWW: http://g-rave.nl/ pgpuvEtLMzJFq.pgp Description: PGP signature
Re: How to enable more than 256 pty's?
On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. Wouldn't get deallocated right away, or wouldn't get deallocated at all? Apparently, it is not unusual for pts reclamation to be delayed a bit by a non-zero refcnt. As per my other mail, they wouldn't get deallocated at all. They still show up in /dev/pts/ even after closing, and the next integer index is picked up upon the next terminal creation. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
* Ed Schouten [EMAIL PROTECTED] wrote: * Vlad GALU [EMAIL PROTECTED] wrote: On 10/2/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Vlad GALU [EMAIL PROTECTED] writes: The symptoms were exhibited even with rev. 1.16. I've CC'ed him so he can catch up with the thread. Which symptoms? I can no longer reproduce the hang-on-close bug. Strangely enough, me neither. In his case, allocated pts' wouldn't get deallocated once the sessions ended. This is a known issue IIRC. See line 245 of tty_pts.c 1.16. Can be easily reproduced by killing the sshd while apps are still running in the shell. I thought we weren't able to destroy the device there, because you can't destroy a TTY when it is used by an application (i.e. when it's the controlling terminal). Thought about this 2 seconds after I sent my message: this is also responsible for the `zombie jails': tty's are made with make_dev_cred, which causes ucred's to be leaked, which eventually causes prisons to be leaked. -- Ed Schouten [EMAIL PROTECTED] WWW: http://g-rave.nl/ pgpcwewwdcX4k.pgp Description: PGP signature
Re: How to enable more than 256 pty's?
Ed Schouten [EMAIL PROTECTED] writes: This is a known issue IIRC. See line 245 of tty_pts.c 1.16. Can be easily reproduced by killing the sshd while apps are still running in the shell. It's not that simple. The question is why t_refcnt 1 when there are no processes left attached to the tty. I managed to reproduce this as follows: $ script -q 1 script -q 2 script -q 3 script -q 4 tty if nothing else is going on at the same time, you should always see the same output, but instead you see a steadily increasing pts number. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Thanks for the tip there but I cant find any function called pty_create_slave
in the source.
N.B. Machine is running 5.4 but I also looked on 6.2 which we could upgrade
to but still couldn't find it, so I assume you may be talking about something
that's in current which we couldn't risk on this machine.
Is this something that's possible on 5.x / 6.2 or something that will need a
lot of work?
Regards
Steve
- Original Message -
From: Dag-Erling Smørgrav [EMAIL PROTECTED]
You need to change the way ptys are named in pty_create_slave() and
pty_clone() in sys/kern/tty_pty.c. Just changing names won't help as
the sequence is also hardcoded in pty_clone().
You also need to change grantpt(), openpty() and any other userland code
which has hardcoded knowledge of the naming scheme:
[EMAIL PROTECTED] ~% gfs pqrsPQRS
src/sys/kern/tty_pty.c: static char *names = pqrsPQRS;
src/sys/kern/tty_pty.c: * pts ==
/dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/sys/kern/tty_pty.c: * ptc ==
/dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv]
src/contrib/telnet/telnetd/sys_term.c: for (cp = pqrsPQRS; *cp; cp++) {
src/usr.sbin/ac/ac.c: strchr(pqrsPQRS,
usr.ut_line[3]) != 0 ||
src/lib/libutil/pty.c: for (cp1 = pqrsPQRS; *cp1; cp1++) {
src/lib/libc/stdlib/grantpt.c: #define PT_DEV1 pqrsPQRS
Alternatively, set kern.pts.enable to 1, and find and fix the
hang-on-close bug in the pts code (if it hasn't been fixed already)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
How to enable more than 256 pty's?
Is it really a matter of editing: /usr/src/sys/kern/tty_pty.c And changing: static char *names = pqrsPQRS; To increase the number of available pty's ( FreeBSD 5.4 ) or is there a nicer way? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to enable more than 256 pty's?
Well looked like that might work but clearly not, should have looked closer. Is there a way to do this? Regards Steve - Original Message - Is it really a matter of editing: /usr/src/sys/kern/tty_pty.c And changing: static char *names = pqrsPQRS; To increase the number of available pty's ( FreeBSD 5.4 ) or is there a nicer way? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
