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.9 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 438791F990 for ; Wed, 5 Aug 2020 20:34:56 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 07E1C385703A; Wed, 5 Aug 2020 20:34:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 07E1C385703A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1596659695; bh=QO4PGXb61/aiDjYElEr6XaaeSpQaOCzNQlJsviu8kxI=; 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=IpnGp1mBBDOAFmlnA3uL46a3dJqxRmkO8TStvBYzoNlZx6O3ci6oLUpDpaGVY1Iz/ D2cDpjgWYyZBhPV3b7F3qJFwPqnZOsnn9OisjGgG1Aooj5r3Eeig/dnnvI0aaGrM0d D1Ld9a28HtAgMz9q71qK2cRNsCQ6ASbQJTMWisoU= Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by sourceware.org (Postfix) with ESMTPS id 7BFBC3857039 for ; Wed, 5 Aug 2020 20:34:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7BFBC3857039 Received: by mail-wm1-x344.google.com with SMTP id t14so7614730wmi.3 for ; Wed, 05 Aug 2020 13:34:52 -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=QO4PGXb61/aiDjYElEr6XaaeSpQaOCzNQlJsviu8kxI=; b=umB14HioTWeK2UMmz4G3n/QW2OP/CNFGmBd3Dk+JdN+/Nzpfc2gCHagsBeKpMnSxB5 HBlo0Kj8HzmohSv65GFt7s1PPpQOnXxh/lC318Ef1fDEBEEWDrokcj5/nETSGHv57a+A FiR9mKCNs/7pUSsCBRxTW6rTIsY7j0LL1x+p6nIEXZChlts/K7/D9pEhumQ24exvACEC PB/TNHWgFjSRaTnGLmXqewRSphNfVAXiEE+/nSJNkAuFromiXeRIdsHPjUficPYV7j7H UaCC0+hweIMVQb7qKp3NAFURz7Ka+2cjPeAtw/nf0g2LIhh8vT+U3YPEE7nqF1cd/Dbj ZO8g== X-Gm-Message-State: AOAM531a4qeiShlt2NBkPwjtFQj6O5V3qLX+CPUrFUA2n24KXtRqKbyh Pr8mUfbH0JUJWaSaIFAZHY0= X-Google-Smtp-Source: ABdhPJzepswJInAl5ekAetAAY6jiS+Q1ju1AzvzXdZ1Ke9ObKOsnUtiTQcRYozMaVq7AKXfa3IUzMQ== X-Received: by 2002:a1c:bc0b:: with SMTP id m11mr4445693wmf.83.1596659691560; Wed, 05 Aug 2020 13:34:51 -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 b77sm3246910wmb.3.2020.08.05.13.34.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 13:34:51 -0700 (PDT) Subject: Re: Pseudoterminal terminology in POSIX To: Geoff Clare , austin-group-l@opengroup.org, Steffen Nurpmeso References: <20200805135110.6Sj7F%steffen@sdaoden.eu> <20200805142049.GA17848@localhost> Message-ID: Date: Wed, 5 Aug 2020 22:34:48 +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: <20200805142049.GA17848@localhost> 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 , "libc-alpha@sourceware.org" , mtk.manpages@gmail.com, enh , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" [Restoring the CC, which seems to have got lost along the way; it's best if we keep it, since some people who are involved on the Linux/Glibc side may not be on the Austin list.] Hello Geoff and Steffen, Thanks for your feedback. On 8/5/20 4:20 PM, Geoff Clare via austin-group-l at The Open Group wrote: > Steffen Nurpmeso wrote, on 05 Aug 2020: >> >> Michael Kerrisk via austin-group-l at The Open Group wrote in >> : >> |Elliot Hughes and I both noticed a point from "Minutes of the 3rd August \ >> |2020 >> |Teleconference": >> .. >> |On Tue, Aug 4, 2020 at 5:52 PM Andrew Josey wrote: >> ... >> |> * General news >> |> >> |> We discussed terminology usage, in particuler terms such as >> |> master/slave, blacklist/whitelist. It was agreed some terminology >> |> for pseudo-terminals could be better described using more functionally >> |> descriptive terms, but the details of this are left to a future bug >> |> report. Andrew and Geoff took an action to investigate further >> |> and come back with an analysis. >> ... >> |The essence of the idea is simple. Let's not invent completely new >> |terms, but rather rework existing (familiar) terminology a little, as >> |follows: >> | >> | pseudoterminal (device) ==> "pseudoterminal device pair" > > I'm okay with that, but ... > >> | >> | slave ==> "terminal device" > > many other things are also terminal devices, so this doesn't work unless ... > >> | (or "terminal end of the pseudoterminal device pair") > > you use this cumbersome phrasing every time you refer to it. (I don't really agree; context is everything; see below.) >> | >> | master ==> "pseudoterminal device" >> | (or "pseudoterminal end of the pseudoterminal device pair") > > This makes no sense to me. Given the phrase "pseudoterminal device pair", > I would naturally expect "pseudoterminal device" could be used to refer > to either of the individual devices in the pair, rather than one and not > the other. So, I think Elliot's mail provided a good response to this. I am probably overcompensating with my language. In practice, it may well be that people settle into the terminology pseudoterminal device pair pseudoterminal terminal And, in the context, and with familiarity, the last two terms will be understood to mean the respective end points, so that we would just talk about "the pseudoterminal and the terminal that compose the device pair". And the fact that many things are terminals doesn't really undermine this; the context would make it clear, I think. >> How about ancillary or accessory terminal device for the slave. > > I think ancillary would actually be more applicable to the master. > >> >> |The resulting language (as it appears in the proposed changes for the >> |Linux manual pages) is reasonably clear, albeit a little clunky in >> |places (wordings like "the (pseudo)terminal end of the pseudoterminal >> |device pair" are clear, but a little verbose). >> >> Yes. It is terrible and absolutely unclear (to me). And >> presumely i would become dazed if i would read an entire manual >> with the above terms. > > I agree, it's too cumbersome. > > My own thoughts up to now had been that, since the slave side is the > side that is intended to be used as a terminal in the normal way, the > slave should be called the "primary" device. I hadn't come up with a > word for the master side, but Steffen's suggestion of "ancillary" works > quite well (I just saw a dictionary definition that said "providing > necessary support to the primary ..."). Notwithstanding my arguments above, I'm not fixed in the terminology that Elliot and I are suggesting, and I would not have a problem with the terms "primary" and "ancillary" (and your [Geoff] suggested association of "ancillary" with the "master" seems more natural than associating it with the "slave"). The point is that if we come up with some terminology that is not hideous, people will adapt. I remain somewhat agnostic about what the terminology should be. Cheers, Michael