unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk \(man-pages\) via Libc-alpha" <libc-alpha@sourceware.org>
To: Zack Weinberg <zackw@panix.com>,
	Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>
Cc: "Michael Kerrisk \(man-pages\)" <mtk.lists@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	linux-man <linux-man@vger.kernel.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	larryd.kbd@gmail.com, ajosey@opengroup.org, gwc@opengroup.org,
	austin-group-l@opengroup.org, mtk.manpages@gmail.com,
	enh@google.com, Joseph Myers <joseph@codesourcery.com>
Subject: Re: Pseudoterminal terminology in POSIX
Date: Tue, 11 Aug 2020 10:32:55 +0200	[thread overview]
Message-ID: <041a0f0f-1b24-69d8-6f05-69d9e92e83d5@gmail.com> (raw)
In-Reply-To: <CAKCAbMgmuha1qTB_TKNSVxKvoWKVU-eG27+G-S9kP6rR021fGA@mail.gmail.com>

Hi Zack,

On 8/10/20 8:10 PM, Zack Weinberg wrote:
> On Mon, Aug 10, 2020 at 9:21 AM Joerg Schilling
> <Joerg.Schilling@fokus.fraunhofer.de> wrote:
>> Larry Dwyer via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
>>
>>> How about the "control" side and the "terminal" side (of the paired
>>> device files)?
>>
>> The Solaris man pty page since a really long time has this:
>>
>>     By default, 48 pseudo-terminal pairs are configured as  follows:
>>
>>        /dev/pty[p-r][0-9a-f] controller devices
>>        /dev/tty[p-r][0-9a-f] slave devices
>>
>> so I would be OK with "controller" side and "terminal" side.
> 
> (libc-alpha, Michael - sorry about not responding to any of this
> thread last week, my actual job has had me swamped.  I still mean to
> give a whack at revising the glibc manual with this terminology but I
> won't be able to get to it until *next* week at the earliest.)
> 
> I like "terminal side" for the tty[p-r][0-9a-f] | pts/[0-9]+ devices,
> but "control(ler) side" still gives the wrong impression IMNSHO.  The
> pty[p-r][0-9a-f] | ptmx devices don't exert any actual control over
> anything.  They are just the other side of a bidirectional
> communication channel.  It's not like USB, where the "master" side is
> the only one that can initiate a data transfer.

Yes, but on the other hand, the program on the master side is often
providing a some kind of "driving" functionality to operate the
program on the salve slide. So the term "control" here doesn't seem
completely out of place. And Joerg's observation that "controller"
is existing terminology in at least one implementation is an 
interesting data point.

> The relationship between "real" terminals and "pseudo" terminals is
> very much like the relationship between remote network sockets and
> loopback sockets.

Well, maybe, but...

> Data received from, or written to, a "real"
> terminal is transferred over a hardware communications channel from/to
> an external device, such as an RS232 serial line or a
> directly-attached console.  With a "pseudo" terminal, on the other
> hand, the data is transferred over a software queue from/to another
> program running on the same computer (e.g. sshd, screen, xterm).  

... the analogy is not obvious (it was only clear to me after
you elaborated it).

> So I
> think an inside/outside metaphor is more appropriate: how about
> "outside", "exterior", or "external" device for the pty[p-r][0-9a-f] |
> ptmx devices ?

We can certainly add it to the list of candidates, but there
are others proposals that feel better to me.

I'll let the conversation run a bit longer, and then try to
summarize the list of proposals we have so far.

Thanks,

Michael

  parent reply	other threads:[~2020-08-11  8:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05 11:21 Pseudoterminal terminology in POSIX Michael Kerrisk via Libc-alpha
2020-08-05 13:51 ` Steffen Nurpmeso
     [not found]   ` <20200805142049.GA17848@localhost>
2020-08-05 20:34     ` Michael Kerrisk (man-pages) via Libc-alpha
     [not found]     ` <CAP1RCkjrqKGJmh6f637D=yGuhev7ae5QJkMjv5a8iHo4X33NFw@mail.gmail.com>
     [not found]       ` <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.camel@gnu.org>
2020-08-05 20:34         ` Michael Kerrisk (man-pages) via Libc-alpha
     [not found]         ` <21048.1596645536@jinx.noi.kre.to>
     [not found]           ` <CAH7i3LrNvBo3indixGyJgS2_4F9r3cd3kOiDgPK8m-ZXj1a0zg@mail.gmail.com>
     [not found]             ` <874bfe40-5f05-151d-42b3-482baacbf0b2@gmail.com>
     [not found]               ` <CAH7i3LpXZxwaLQTY=XK8zM4jWYHSiy1feA6ZLE-mT-ZiJNak5A@mail.gmail.com>
2020-08-11  8:31                 ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-08 23:18 ` Larry Dwyer via Libc-alpha
2020-08-10 13:20   ` Joerg Schilling
2020-08-10 18:10     ` Zack Weinberg
2020-08-10 18:17       ` Samuel Thibault
2020-08-10 18:21         ` Samuel Thibault
2020-08-11  8:32       ` Michael Kerrisk (man-pages) via Libc-alpha [this message]
2020-08-10 13:58   ` Thor Lancelot Simon
2020-08-11  8:31     ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-11 11:51       ` Thor Lancelot Simon
2020-08-11 14:20         ` Michael Kerrisk via Libc-alpha
2020-08-12 14:37       ` Thor Lancelot Simon
2020-08-11  8:32   ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-11 17:29     ` Joshua M. Clulow via Libc-alpha
2020-08-12 13:19       ` Steffen Nurpmeso
2020-08-18 16:10         ` Dave Martin
2020-08-18 16:44           ` enh via Libc-alpha
2020-08-11 11:17   ` Dirk Fieldhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=041a0f0f-1b24-69d8-6f05-69d9e92e83d5@gmail.com \
    --to=libc-alpha@sourceware.org \
    --cc=Joerg.Schilling@fokus.fraunhofer.de \
    --cc=ajosey@opengroup.org \
    --cc=austin-group-l@opengroup.org \
    --cc=enh@google.com \
    --cc=fweimer@redhat.com \
    --cc=gwc@opengroup.org \
    --cc=joseph@codesourcery.com \
    --cc=larryd.kbd@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.lists@gmail.com \
    --cc=mtk.manpages@gmail.com \
    --cc=zackw@panix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).