From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id 040863851C0D for ; Tue, 18 Aug 2020 16:44:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 040863851C0D Received: by mail-lj1-x235.google.com with SMTP id h19so22169363ljg.13 for ; Tue, 18 Aug 2020 09:44:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NF7izPAtnNs0ARQH2+brT3n6vf5PQBYyUjsZ8fd0r1g=; b=H1sRGapD/Hx2BWss4A9DoqMYLacWEqnqPOEfd8Li7nSrzojrzC1ii1AVMXdHQTaECQ MYPbE9U1LJquy/ZAg9NoWhu7qRlMYFBxtcP9ZQZGiIbEpLPkcvyyrq7KWs0noxPmMK80 bCOaVPVisH5O0FcJnVAfdbGm6m55HN/+nE0j2ZVwYDGf6nrJMgiqtLnlj4WZ5dBeeJPz pet/8XZJevRjGAnDg8HAguB7lkLwepT4IPViB8LL2U9WhK5aFNh3PkizzJOzfceuYPV6 Az+xGdnpMt7fbpIO7rpM58EqDxvwHIUFtJAbze1FnhgxINqjj+baeGuFs+bCLeLHgJQ8 SC4Q== X-Gm-Message-State: AOAM532P6ju7zLRqHZM0iKzokm8UrgsdLQtixTPfqc/BswWUfsnIKVME TKaBY9HL4inoSpfxS7K0x6NUxavdXq+7IvWTpD7t/g== X-Google-Smtp-Source: ABdhPJzIRpFfRP5mRXNTu0S2ZEmJ0/W72GkIGDcJT+i+qv1GDIbdwrwa9F68T0hFVbg/Q752M8bVbC0zKtBx0yfjAoc= X-Received: by 2002:a2e:a36a:: with SMTP id i10mr10239397ljn.46.1597769060258; Tue, 18 Aug 2020 09:44:20 -0700 (PDT) MIME-Version: 1.0 References: <20200812131900.JbiVo%steffen@sdaoden.eu> <20200818161053.GC6642@arm.com> In-Reply-To: <20200818161053.GC6642@arm.com> From: enh Date: Tue, 18 Aug 2020 09:44:06 -0700 Message-ID: Subject: Re: Pseudoterminal terminology in POSIX To: Dave Martin Cc: "Joshua M. Clulow" , "Michael Kerrisk (man-pages)" , Larry Dwyer , Florian Weimer , linux-man , Andrew Josey , libc-alpha , Joseph Myers , austin-group-l X-Spam-Status: No, score=-19.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:44:24 -0000 On Tue, Aug 18, 2020 at 9:11 AM Dave Martin 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 > > : > > |On Tue, 11 Aug 2020 at 01:33, Michael Kerrisk man-pages via > > |austin-group-l at The Open Group 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 >