pseudo terminals in 7.0 - pts implementation

[Dan Epure]

Hi,

For the moment this feature is only available in HEAD. I think the limit is "only" 512 master/slave pairs.
Should be enough for this year. Is it going to be merged  in 6.3 ? 
Thanks again.
 
On Thu, Nov 22, 2007 at 08:53:36AM +0000, Robert Watson wrote:
>
> 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
>>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"