All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.lists@gmail.com>
To: Zack Weinberg <zackw@panix.com>,
	Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>
Cc: mtk.manpages@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, gwc@opengroup.org,
	austin-group-l@opengroup.org, ajosey@opengroup.org,
	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:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05 11:21 Pseudoterminal terminology in POSIX Michael Kerrisk
2020-08-05 13:51 ` Steffen Nurpmeso
     [not found]   ` <20200805142049.GA17848@localhost>
2020-08-05 20:34     ` Michael Kerrisk (man-pages)
     [not found]     ` <CAP1RCkjrqKGJmh6f637D=yGuhev7ae5QJkMjv5a8iHo4X33NFw@mail.gmail.com>
     [not found]       ` <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.camel@gnu.org>
2020-08-05 20:34         ` Michael Kerrisk (man-pages)
     [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)
2020-08-08 23:18 ` Larry Dwyer
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) [this message]
2020-08-10 13:58   ` Thor Lancelot Simon
2020-08-11  8:31     ` Michael Kerrisk (man-pages)
2020-08-11 11:51       ` Thor Lancelot Simon
2020-08-11 14:20         ` Michael Kerrisk
2020-08-12 14:37       ` Thor Lancelot Simon
2020-08-11  8:32   ` Michael Kerrisk (man-pages)
2020-08-11 17:29     ` Joshua M. Clulow
2020-08-12 13:19       ` Steffen Nurpmeso
2020-08-18 16:10         ` Dave Martin
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

* 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=mtk.lists@gmail.com \
    --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=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.