From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 256E1386101F for ; Mon, 27 Jul 2020 20:52:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 256E1386101F Received: by mail-lj1-x22c.google.com with SMTP id b25so18776465ljp.6 for ; Mon, 27 Jul 2020 13:52:48 -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=KF0L+/gxympYMMvXeIxaVuEvIh/W4Ghp51w1vsjcCcs=; b=fpjkE7AqMK/L9i1SUdablI4H65YaRjz6EQONN5UBoVP8ntL5C8ZlKe0xV/KtLW7mO5 xUEWkAh+6Sm5c3Z0ZV84s5Qx83HCsBOtYQ1Gf9b984ATKATS/PmDV7qzh1KbrhIpAtQE b9QHQx5JYXxKMNWUn373huvYLFLYxFUaKjgNTujCI/EwJEBaLxD+IijVX88sv27JMRpO 3Yl3h84wVHijIN4CmQIEl2HvIfvP17/7CVHQccAuG5ARYKs2ja02BYsqBKNClyvqCB7+ Xmr4ykdBYU+x+NnMPfymuDiem+7QPo243R6FDFNfM7/O1Pvz97awpffjIhLlaBmm4mz4 2CTQ== X-Gm-Message-State: AOAM532+S14RjCoOzQwCxsfnTG2IQR7QnZnONyLYWD7jdPAfj0TRIUsr rmXLT5CodIb9l/G/w6NU2UsaY3PEzflVH8yri4F6Mw== X-Google-Smtp-Source: ABdhPJzUSZLKxA98+DDQVuMPaKP0XV7GR6M8n5mXb5M9fVBg/RPzT0TPA5pnukSVY/sxGp774ku0ERVx0M7k3uOwltU= X-Received: by 2002:a2e:9d84:: with SMTP id c4mr10993606ljj.46.1595883166513; Mon, 27 Jul 2020 13:52:46 -0700 (PDT) MIME-Version: 1.0 References: <423fbe8b-6b41-d9e8-c4a2-5865d8eeec4b@gmail.com> In-Reply-To: <423fbe8b-6b41-d9e8-c4a2-5865d8eeec4b@gmail.com> From: enh Date: Mon, 27 Jul 2020 13:52:34 -0700 Message-ID: Subject: Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?) To: "Michael Kerrisk (man-pages)" Cc: Zack Weinberg , "Carlos O'Donell" , libc-alpha , "Joseph S. Myers" , Florian Weimer , Paul Eggert X-Spam-Status: No, score=-18.8 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, KAM_SHORT, 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: Mon, 27 Jul 2020 20:52:50 -0000 On Mon, Jul 27, 2020 at 1:32 PM Michael Kerrisk (man-pages) < mtk.manpages@gmail.com> wrote: > [I'm just threading Elliot into this discussion, because he works on > Android > and has an interest in finding also better terminology here. ] > > On 7/6/20 11:13 AM, Michael Kerrisk (man-pages) wrote: > > Hello Zack. > > > > On 7/4/20 6:52 PM, Zack Weinberg wrote: > >> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk > wrote: > >>> > >>>> That said I think this is not as important as other, similar, changes > >>>> we could make. For instance, the term "master" is used _along with_ > >>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that > >>>> chapter to eliminate that terminology as soon as I find the time. > >>>> Anyone want to beat me to it? > >>> > >>> No, but please include me in the discussions. It would be good if libc > >>> and man-pages could find common terminology. > >>> > >>> But I agree also with Joseph that the scope is wider and we should > >>> think about what terminology POSIX might (be convinced to) switch to. > >>> > >>> Unlike Florian, I'm not excessively attached to the need to settle on > >>> a name that starts with 's'. I think it might be too easy to get into > >>> knots trying to find names that match 'm' and 's', and one should at > >>> least allow for the possibility of good names that don't fit with > >>> those letters; what would be best, IMO, is names that "feel right". > >> > >> I agree. In particular I think there is no reason to struggle with > >> coming up with terms that fit "ptmx" and "pts" because BSD ptys use > >> totally different device node names anyway (tty[pqrs...]NN and > >> pty[pqrs...]NN) and there's no hope of finding something that works > >> with both. > > > > (Good point.) > > > >> I don't want to commit to terminology until I've had a go at rewriting > >> the manual, because I think doing the rewrite will be the easiest way > >> to figure out whether the new terms are good, > > > > I think that's a good text engineering approach. I think it's fine > > to cycle through a number of ideas, rejecting them until something feels > > "right". > > > >> but what I'm currently > >> thinking is: > >> > >> "pty master device" -> "pty line-side device" or "outside device" > >> "pty slave device" -> "pty host-side device" or "inside device" > >> /dev/ptmx stands for "pseudoterminal multiplexer" > >> /dev/pts stand for "pseudoterminals (directory of)" > fwiw, until the topic came up recently, i'd believed since the 1990s that that's /dev/ptmx and /dev/pts stood for anyway: multiplexer and a plural. > >> Currently I like "line-side" and "host-side" because it seems like a > >> natural generalization from true terminal device nodes (which are > >> always host-side) to pseudoterminals (additionally have a line-side > >> device node). And it can generalize to the relationship between > >> Linux's /dev/ttyNN and /dev/vcs(a)NN as well. > > > > So far, "line-side" and "host-side" don't do it for me. But maybe > > I just need time to sit with those terms to get used to them. yeah, i'm can't say i'm particularly excited about those terms ... but "master" and "slave" weren't super obvious either. tbh, i don't think any of the choices in this thread are actually _worse_ in terms of clarity (though existing practice was at least consistent so you could rtfm). i found the python reference i failed to find for michael earlier... it looks like i couldn't find it because it's the one master/slave change to python that they didn't actually submit. in https://github.com/python/cpython/pull/9100 they were going to go with parent and child but gvanrossum said they shouldn't change unless Unix changes. at least parent/child are names that most folks (including non-native speakers) will have had to learn already. golang went with pty/tty ( https://github.com/creack/pty/commit/7dc38fb350b1d71383eed149e73acb7bae231ddb) which is interestingly simple. > > > As we consider names, I think it's good to keep in mind the rather > > diverse set of applications where pseudoterminals are used, including > > > > ssh etc. > there was some trolling about the commit on the openbsd mailing list which is why i've seen it, but afaict they've only renamed blacklist/whitelist so far. > > xterm etc. > > expect > > tmux > > script > > unbuffer > > > > I just throw out some ideas (in the order master, slave): > > > > "driver" device plus "terminal" device > > "driver" device plus "client" device > > "proxy" device plus "terminal" device > > "proxy" device plus "client" device > > > > I'm not arguing that these are better than your terms. (At least, > > not yet ;-).) But I think it's useful to throw a lot of ideas into > > the mix, in the hope of sparking further ideas from others. > > > > Cheers, > > > > Michael > > > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ >