Pseudoterminal terminology in POSIX

[enh]

On Tue, Aug 18, 2020 at 9:11 AM Dave Martin <Dave.Martin@arm.com> wrote:

> On Wed, Aug 12, 2020 at 03:19:00PM +0200, Steffen Nurpmeso wrote:
> > Joshua M. Clulow via austin-group-l at The Open Group wrote in
> >  <CAEwA5nKtyJTnQEXZZaiHywTpfDCprmupnCiq9kf5oupV7iG8RA@mail.gmail.com>:
> >  |On Tue, 11 Aug 2020 at 01:33, Michael Kerrisk man-pages via
> >  |austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
> >  |> On 8/9/20 1:18 AM, Larry Dwyer via Libc-alpha wrote:
> >  |>> How about the "control" side and the "terminal" side (of the paired
> >  |>> device files)?
> >  |>
> >  |> Thanks for the suggestion. As far as I'm concerned, that would
> >  |> also be an option worth considering.
> >  |
> >  |I work on the illumos project and a few of us have been having a
> >  |(not yet public) discussion about this lately as well.  I think the
> >  |best one we could think of was:
> >  |
> >  |    the "control" side for the result of posix_openpt()
> >  |
> >  |    the "subordinate" side for the result of ptsname() and open(),
> >
> > You know, (In)Subordination has a very military touch, with
> > exclamation mark many may have heard it.  Also in traditional
> > (white western world) education as such.  Like in first the
> > pizzle, then the bull pizzle, maybe.  So to say.  In my ears this
> > sounds more aggressive and weird than slave, in a technical
> > combination of master/slave, ever could.
> > Also isn't it a bit submissive here; it is under control, but
> > other than that.
> >
> >  |    "/dev/pts" still makes sense, etc
> >  |
> >  |    we would rename our "/dev/ptmx" device file the "manager
> >  |    driver" rather than the "master"
> >  |
> >  |We would strongly consider using the same shift as other projects,
> >  |but I think only if they actually make sense; e.g., the "terminal"
> >  |and "pseudoterminal" end doesn't really stand out as completely
> >  |clear.
> >
> > Manager sounds strange here, i always liked manager/worker
> > terminologie for threads, and used them like that (and am the
> > opinion that .. but that is something different and has sailed),
> > but for a pseudo terminal?  I think that if the standard wants to
> > be future proof manager should be avoided.  These guys induce
> > strange, ruthless and devastating decisions which destroy life on
> > earth (as we used to know it), so i for one do not want to be
> > harassed by such a term.
>
> Was this discussion concluded yet?
>

no, but fwiw i've moved Android's libc over to pty/tty. if POSIX does make
a change, i can easily change again.

that said, i intend to keep pty and tty in the _code_, because they're a
good deal less unclear than the almost meaningless master and slave were
and -- despite having heard a *lot* of suggestions at this point -- i'm
honestly not expecting anything better than pty/tty...


> Question: was there ever an intention that a pty master-slave pair
> should resemble two real terminals connected to each other?  (e.g., two
> serial ports on the same machine, cabled together).
>
>
> POSIX seems pretty vague as to whether the pty master counts as a
> terminal or not.  In Linux, it has many but not all of the properties
> of a terminal.  It's not at all clear whether this is intentional, and
> I don't know whether other implementations behave similarly.
>
> The main distinctions I'm aware of are that the pty master cannot become
> the controlling terminal of any process, and that both master and slave
> have rather weird dialin/hangup semantics which appear rather ad-hoc and
> don't map nicely onto the behaviour of physical terminal lines.
>
> The master also has a few extra ioctls at its disposal for managing the
> pair.
>
> Other stuff does work identically on the pty master and slave though,
> such as setting termios modes.  I have a vague memory of successfully
> setting ECHO on both ends...
>
>
> IMHO, the real problem here is that pty devices are underspecified,
> and counterintuitive in some areas.  Changing the nomenclature won't fix
> that.
>

...because of this. as far as i'm concerned you either know what you're
doing (and pty and tty are helpful enough, and conveniently match the
functions that apply to them ["is there a 'p' in the name?"]), or you're
going to have to read the man page anyway, and the man page can cover all
the gory details and weird historical cruft in a way that's never going to
fit into something short enough to be used as a name.


> Plus, renaming things won't kill off the old terminology, and with both
> naming schemes in circulation, people are likely to be even more
> confused than they were to start with, no?
>

that's what i like about pty and tty. not perfect, but definitely less bad
than what we had in terms of "what is this, and what can i do with it?".

but, yeah, you're going to be spending a lot of time with the documentation.


> Cheers
> ---Dave
>