From owner-freebsd-hackers Sat Dec 26 13:38:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03937 for freebsd-hackers-outgoing; Sat, 26 Dec 1998 13:38:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ywing.creative.net.au ([203.26.193.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03932 for ; Sat, 26 Dec 1998 13:38:46 -0800 (PST) (envelope-from adrian@ywing.creative.net.au) Received: from ywing.creative.net.au (localhost.speedport.net [127.0.0.1] (may be forged)) by ywing.creative.net.au (8.8.8/8.8.8) with ESMTP id WAA04817 for ; Sat, 26 Dec 1998 22:38:04 +0100 (CET) Message-Id: <199812262138.WAA04817@ywing.creative.net.au> To: freebsd-hackers@FreeBSD.ORG From: adrian@FreeBSD.ORG Subject: auto-allocation of ptys Date: Sat, 26 Dec 1998 22:38:02 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got sick of running out of ptys while running X, and having to result in rebuilding a kernel with more ptys enabled. So, I modified sys/kern/tty_pty.c to dynamically allocate pt_ioctl and tty structs when a pty access is made. I'm not totally familar with the tty IO system just yet, so it creates the structs whenever *some* form of access is done, not just open(). It also doesn't return the memory used by pt_ioctl and tty structs back to the memory pool - I didn't think the code complexity it would add would justify it. The patch is relative to sys/kern/tty_pty.c in 2.2.7-REL . Redefine MAXPTY in the source to set the initial number of ptys to allow to be opened. It creates two sysctl variables - kern.maxpty and kern.openptys - it allows you to set the max number of ptys you can have opened, and shows the current number of ptys opened respectively. This patch breaks pstat -t (strangely enough :) ... I haven't looked at it yet, but I guess you would have to just walk the pt_dynpty linked lists to grab the open ptys and go from there. It also will break devfs - I'm sure a devfs solution could be nutted out, but I'm still looking at it atm, and I'm not entirely sure on the status of it. The upshoot of all this of course is that you don't have to rebuild your kernel whenever you need more ptys. :-) Does anyone want to take a look at the idea and comment on it ? Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message