From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 09:01:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19DAB16A46C; Thu, 22 Nov 2007 09:01:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E3BBC13C45A; Thu, 22 Nov 2007 09:01:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3EF7947370; Thu, 22 Nov 2007 03:56:37 -0500 (EST) Date: Thu, 22 Nov 2007 08:53:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dan Epure In-Reply-To: <20071122065956.GH19354@iogyte.ro> Message-ID: <20071122085228.M60495@fledge.watson.org> References: <20071118012616.GF19354@iogyte.ro> <20071118144243.B97497@fledge.watson.org> <20071121215807.F60495@fledge.watson.org> <20071122065956.GH19354@iogyte.ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, csjp@FreeBSD.org, jhb@FreeBSD.org Subject: Re: pseudo terminals in 7.0 - pts implementation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2007 09:01:16 -0000 On Thu, 22 Nov 2007, Dan Epure wrote: > Thank you for your answer. In this case the first problem (gnu screen) does > not deserve any attention because it is related to the ptmx clonig. My goal > is to find a way to increase the number os pseudo terminal. the traditional > 256 pty is not sufficient for my needs. Is there any way to do this on > freebsd other than using ptmx cloning ? John Baldwin has just merged support for up to 1024 ptys using the traditional pty driver, I believe, to HEAD, and plans (or perhaps has already) merged it to 7.0. I see no reason not to further merge it to 6.x. I've stuck him on the CC list also. Robert N M Watson Computer Laboratory University of Cambridge > > > On Wed, Nov 21, 2007 at 10:00:02PM +0000, Robert Watson wrote: >> >> On Sun, 18 Nov 2007, Robert Watson wrote: >> >>> On Sun, 18 Nov 2007, Dan Epure wrote: >>> >>>> 7.0-BETA3 still has issues regarding the pts implementation . problems >>>> found: 1. - GNU screen: starting a screen, opening a few windows and >>>> quiting screen leaves the allocated pseudo terminal in use. 100 screen >>>> user, using each one opening 10 windows will deplete the default of 1000 >>>> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates >>>> an additional entry in /dev/pty/. when the number of entries equals >>>> kern.pts.max the system became unusable. >>> >>> The first of these is likely a reference management bug of some sort -- I >>> find that if I close a pty in screen by exiting the shell, the pts device >>> is GC'd properly, but if I close it by killing the session with ctrl-k, >>> then the pts device is not properly GC'd and processes hung off it not >>> properly killed. I believe that closing the master device is not properly >>> kicking the slave device and causing its consumers to exit, hence the pts >>> device not being closd and released. Christian was taking a look at this >>> a couple of days ago, and I've CC'd him. >>> >>> The second problem is more tricky, and has to do with the cloning model. >>> Similar problems can exist with other variations on the ptmx >>> implementation, and I need to give some thought to how to address this. >> >> Dan, >> >> So, thinking a bit more about the second problem, I think it is inherrent >> to the way we've designed the /dev/ptmx cloning model, which is >> unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 >> and put together a revised one for 7.1. The reason to do this is to avoid >> encoding the user<->kernel interface for allocating pty's via ptmx along >> the current lines, which we'd then need to continue supporting in future >> releases. I'm going to spend a bit of time over the next day or two >> looking at revising the interface to fix these problems. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >