From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by sourceware.org (Postfix) with ESMTPS id 353813858D35 for ; Mon, 27 Jul 2020 20:32:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 353813858D35 Received: by mail-ej1-x643.google.com with SMTP id l4so18338193ejd.13 for ; Mon, 27 Jul 2020 13:32:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8MLpbuJUP/BfUAggep9k6e/Ldb8eqr66Q7F3OJaWdI8=; b=Ly2XgCPRY3xMTmY42VHIkS7UfQFdVLOzTBjm6BDPgGmNHMYmHzAjaejjgnrAcS5plB A8aa08SoHN8tXCOX7Q1/7ux3uPULtOqYpkqts7Xv5cPt+0XwP+ZpiJcUajLnAtGnwRIa r6rQ9OUiz4gi0u7n1cYNNgrAR8X8WsLrCOIZIiHhAsHJmwSsxIrFqrOvHpVLzt0vlyJh hT9+1QJe2EV7asCa0eprCKo/H5ElbXQXpCP/Z3DGIVJiPk4MozYE2SFXEo8uOQHxr34l 45gmpcN3ICwkUWYEQXCCmoiM4ZUCWbS/OrtwIKv2C7SBZf1rI4ZZdbEVfNvENQW921PS v9XQ== X-Gm-Message-State: AOAM530Y9C6CBJRHvknQi/sBNSBcGqnuezVEqh49fY6OaJU9DALo0fKa smecQbR7PAvz/bELBPKr43o= X-Google-Smtp-Source: ABdhPJyaIxhfhykwF6FuECfRpI9QA6/QnUCcOc850VFLS9uL7ji7h0y6zRfoIa9JZ4w5t99CUFCmYg== X-Received: by 2002:a17:906:c18d:: with SMTP id g13mr18306153ejz.239.1595881954568; Mon, 27 Jul 2020 13:32:34 -0700 (PDT) Received: from ?IPv6:2001:a61:3adb:8201:9649:88f:51f8:6a21? ([2001:a61:3adb:8201:9649:88f:51f8:6a21]) by smtp.gmail.com with ESMTPSA id d19sm7547654ejk.47.2020.07.27.13.32.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2020 13:32:33 -0700 (PDT) Cc: mtk.manpages@gmail.com, Carlos O'Donell , libc-alpha , "Joseph S. Myers" , Florian Weimer , Paul Eggert , Elliot Hughes Subject: Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?) To: Zack Weinberg References: From: "Michael Kerrisk (man-pages)" Message-ID: <423fbe8b-6b41-d9e8-c4a2-5865d8eeec4b@gmail.com> Date: Mon, 27 Jul 2020 22:32:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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:32:37 -0000 [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)" >> >> 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. > > 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. > 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/