GNOME Bugzilla – Bug 670758
Add support for allocating BSD PTYs through openpty(3)
Last modified: 2015-12-15 13:15:53 UTC
Created attachment 208368 [details] [review] Diff against vte-0.30 implementing the openpty "backend" The diff attached allow systems like OpenBSD, that does not implement the Unix98 PTY family of functions, to allocate pseudo-tty using the openpty(3) BSD function instead of relying on the gnome-pty-helper. For the moment, to use the openpty "backend" instead of the getpt/ptsname/grantpt/unlock one, the packager should specify the '--enable-bsd-pty' option at configure time.
This patch has been committed to the OpenBSD ports tree and the vte package will use bsd-pty by default now. I'm been running with it for several days, it works great and allows us to get rid of the pty-helper.
Can anyone review this please. I would like to push it since it's a great improvement for us not having to rely on the pty-helper. Thanks.
Created attachment 209061 [details] [review] implement a backend for openpty() Amended from op's patch to fix indent.
I don't like the configure switch to enable this. Instead, the code should be structured so that openpty is used if _vte_pty_getpt will always return -1 (that is, neither HAVE_PTSNAME_R, HAVE_PTSNAME nor TIOCGPTN are defined, but HAVE_OPENPTY is defined. Does openpty do all the stuff with the slave fd that _vte_pty_open_unix98() does manually? Or is that not relevant for bsd?
Created attachment 209262 [details] [review] openpty backend without configure switch (In reply to comment #4) > I don't like the configure switch to enable this. Instead, the code should be > structured so that openpty is used if _vte_pty_getpt will always return -1 > (that is, neither HAVE_PTSNAME_R, HAVE_PTSNAME nor TIOCGPTN are defined, but > HAVE_OPENPTY is defined. New diff attached doing this. > Does openpty do all the stuff with the slave fd that _vte_pty_open_unix98() > does manually? Or is that not relevant for bsd? Yes it does, here's an extract from its man page: The openpty() function works in the following way: first it attempts to allocate the pseudo-tty through the /dev/ptm device (see pty(4) for details) and if that fails it searches for a free pseudo-tty by iterating through all existing pseudo-tty devices in /dev. When a free pseudo-tty is found, its ownership is changed to the UID of the caller, permissions are set to correct values, and all earlier uses of that device are revoked (see revoke(2) for details). Is it OK like this, or am I missing something else?
That should cover it, thanks! I modified the patch a bit an pushed to vte-0-32; can you check that I didn't break it :-)
Nothing broke, works just fine here. Thanks ;)
According to bug 759346 comment 0, openbsd now has posix_openpt [http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/posix_openpt.3]. So is the openpty() code path still necessary, or can it be removed and *BSD use the posix_openpt code path like linux?
FWIW libvte now uses posix_openpt() on OpenBSD so I'd guess that removing the openpty() backend won't hurt anyone. Here's what I get on a -current system: $ nm /usr/local/lib/libvte.so.14.1 |grep openpt U posix_openpt