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>