Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jan 2006 09:58:31 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Alexander Leidinger <Alexander@Leidinger.net>
Cc:        current@freebsd.org
Subject:   Re: HEADS UP: pts code committed
Message-ID:  <20060126091933.U97024@fledge.watson.org>
In-Reply-To: <20060126094038.ee2c8pk8go0k80kw@netchild.homeip.net>
References:  <20060126022854.GA16323@ci0.org> <20060126020818.K97024@fledge.watson.org> <20060126094038.ee2c8pk8go0k80kw@netchild.homeip.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 26 Jan 2006, Alexander Leidinger wrote:

> Robert Watson <rwatson@freebsd.org> wrote:
>
> - Allows more linux programs to work. AFAIR I was told the Mathematica 
> developers specially added code to not bail out if no pts device was 
> available (but I mey remember a detail wrongly...).

While this isn't surprising, it's also not very smart.  It would be nice if 
Mathematic used the single unix spec APIs for pty's, as they do work 
differently on many platforms.  Olivier did the Linux compat support but I've 
not tried it as yet.

>> - Can run side-by-side with the old pty driver so that applications 
>> expecting
>>   hunt-and-peck lookup of a new pty, old pty names, and old pty security
>>   properties can still get it.  This means old binaries, even statically
>>   linked, can continue to run.
>
> "Can" as in "you have to enable it", or as in "does already by default"?

They work by default currently, as compiling in pty support compiles in both 
tty_pty.c and tty_pts.c.  The "tricky" thing is that in order to provide 
backwards compatibility for old libc versions, you either have to provide the 
old kernel interface (i.e., /dev/{tty,ptyXX}) or provide updates to old libcs. 
Even then it's a problem because not all programs use the libc interaces, some 
simply try pty's until they find one.  I'm not yet sure how easy we will find 
it to turn off tty_pty.c -- like COMPAT_FREEBSD4, it may need to be on by 
default for some time to come.  Linux also continues to support the old pty 
system, FWIW, even though applications use the new system by default. 
Presumably this is for the same reason.

>> - Sysctl to indicate to recent libc what type of pty to use -- presumably 
>> the
>>   default will change after lots of exposure, testing, and review.
>
> So the sysctl is only for libc and we're encouraged to test the use of the 
> "pts by default" mode?

Yes -- the only affect of the sysctl is to influence libc's selection of one 
or the other pty mechanism as a default.  Originally we had an environmental 
variable for this, but a sysctl can be set using DDB or from any process, and 
setting environmental variables is prone to configuration error, security 
holes, and general discomfort due to requiring that variables be inherited 
from a parent.

Robert N M Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060126091933.U97024>