From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D1B611F66E for ; Tue, 11 Aug 2020 08:33:01 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 159A73861800; Tue, 11 Aug 2020 08:33:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 159A73861800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1597134781; bh=Jpk5BFbj6UKeVfTjgHgwwhPbBqIHStSXe+uluAFaKAM=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=QSLaquFXSlMMTdniNEgGENIqhOSWrbMhoIjC9KiAUW8MXW2o9fE0bA6BCO75uotiF rk2F07Bqk+RdbVZG/jrKSvhF7PYtyyXDkOlAHDUJ6+TKHtqcML04+RYYxT1Zu4zhhK bi6TR9Ylzw2MsN+0KVg3MckpmGd3H2QP531crG+g= Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by sourceware.org (Postfix) with ESMTPS id 679393857C65 for ; Tue, 11 Aug 2020 08:32:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 679393857C65 Received: by mail-wr1-x443.google.com with SMTP id r4so10634116wrx.9 for ; Tue, 11 Aug 2020 01:32:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:cc:subject:to:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Jpk5BFbj6UKeVfTjgHgwwhPbBqIHStSXe+uluAFaKAM=; b=poG6a8JiHArMKTEQVPNP/uGGAWnZ/hQe1H4Jb81dCEKs5E0nNCcWIu28JjVxIw2OCt 628q1zI8Vp85PhKINExOtfgqpLkclgs+z0y2Wmdq4Pn3zGxKMV5iJy9JaECDsCrTTDKk Dm9ZqX3lmQtVoTNkx++2MEe452onen69gkUlOBvfDsnaj41JmlgSr9A7eMDzANop1oMB X42B+qy5FgQjA21CQ3prrD1Khh+775BNltORgli8ZBSHHV3c305rw18jZ5IHAXbSho56 T8tRYY5qpuKtrXedaLlf9RxZ4G/PhCPJUgNYIdUmKYks8M7c8YzvxzgRv9SeDA2692NY EzEA== X-Gm-Message-State: AOAM530iiFRtqZRX7EaMz5pld+ot/PyDFazO5i67tQeaObounowQQJpt lXIKFYWQA45fJ+2W6+tCwlI= X-Google-Smtp-Source: ABdhPJw00T/Rq7qRVU8eG/j3gXNGje1kGuogdXBCNU2hB5a7XgWhM1+467Q9yPwayFSApqSe2vK9cA== X-Received: by 2002:a5d:5588:: with SMTP id i8mr28429811wrv.177.1597134776559; Tue, 11 Aug 2020 01:32:56 -0700 (PDT) Received: from ?IPv6:2001:a61:241a:1101:8c63:f991:aa91:da82? ([2001:a61:241a:1101:8c63:f991:aa91:da82]) by smtp.googlemail.com with ESMTPSA id d14sm24963715wre.44.2020.08.11.01.32.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Aug 2020 01:32:55 -0700 (PDT) Subject: Re: Pseudoterminal terminology in POSIX To: Zack Weinberg , Joerg Schilling References: <6425d636-7f48-3a73-ef0e-7bb5b991360c@gmail.com> <5f3149ad.G/e/1Ac5SJF38sra%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <041a0f0f-1b24-69d8-6f05-69d9e92e83d5@gmail.com> Date: Tue, 11 Aug 2020 10:32:55 +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-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: , From: "Michael Kerrisk \(man-pages\) via Libc-alpha" Reply-To: mtk.manpages@gmail.com Cc: "Michael Kerrisk \(man-pages\)" , Florian Weimer , linux-man , GNU C Library , larryd.kbd@gmail.com, ajosey@opengroup.org, gwc@opengroup.org, austin-group-l@opengroup.org, mtk.manpages@gmail.com, enh@google.com, Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Hi Zack, On 8/10/20 8:10 PM, Zack Weinberg wrote: > On Mon, Aug 10, 2020 at 9:21 AM Joerg Schilling > wrote: >> Larry Dwyer via austin-group-l at The Open Group 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