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, 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 843CA1F66E for ; Tue, 11 Aug 2020 17:29:44 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 72EF33850405; Tue, 11 Aug 2020 17:29:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 72EF33850405 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1597166983; bh=/s61rSkiOseXW43LDVy/P9Oy+oq8rWhujfDX8qCU1h4=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=CV260OFzmS575Sb8puYzSO8sLnHQQjSC95QrvvDRmatnXm7wEl6Bm2twpI4/dYgVa kg6q7J0xBtX/Xro0gOLh17sf+qjcBaFfNBN1kC/I0+hoZZutpU6pnUSHlGk7Pslfm9 GyBuFfYAGVWDw0Osa6pTREiQuOCw7oOeI2AzoB2A= Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 91DD43857C79 for ; Tue, 11 Aug 2020 17:29:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 91DD43857C79 Received: by mail-il1-x143.google.com with SMTP id t4so11410411iln.1 for ; Tue, 11 Aug 2020 10:29:40 -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=/s61rSkiOseXW43LDVy/P9Oy+oq8rWhujfDX8qCU1h4=; b=hUOpazMlqIP+lj6nC0+NYS15dkE599lwDBPQd84LMqO9IlZt8+cRfjRFRVlikw9tPk 0gUS+wpTNS3dNn06B/MotA+H/yOly9sWR2ofFNV4ug7Xit4IYxSzC2j+poF7usT7LnwX Ugpm0Oc5kTCySq4KWZK2t7wtvB4sqyFAx7Z3+4p2KuA+JjbUjrxOAbcFi8vfwDSgF/9D lzZMJxN837RE+u6nEYNP30slRCZM42V7pPwiHA+D19R72IXuOC/58/0KyQdJ/YmqjFe3 h7YTOT6VDgQ/+RM2LZWn92zMZch34XKFDpmFWiOY3C5vfI8/czLJC5tqUa8zRvH1NDzg uM/w== X-Gm-Message-State: AOAM531XaXYgkxDAkJvutQ5BTUOaPuxJ9i25F97a358EB9McLcbzvxF/ bdgzwe+9BEDp+xkx/P/jtxrn35z42xx5UfNq/kB9yg== X-Google-Smtp-Source: ABdhPJyWhh/e2gkCYOwRBEa4F54GILxf967/r99zhgu+YxuneQzyf4c75YqS4LbXeIp4JrnhT98aal7WuwA9y9caKlk= X-Received: by 2002:a92:4a02:: with SMTP id m2mr8730961ilf.258.1597166980101; Tue, 11 Aug 2020 10:29:40 -0700 (PDT) MIME-Version: 1.0 References: <6425d636-7f48-3a73-ef0e-7bb5b991360c@gmail.com> <722119e5-9047-7c47-0d1c-2afeb946d5ca@gmail.com> In-Reply-To: <722119e5-9047-7c47-0d1c-2afeb946d5ca@gmail.com> Date: Tue, 11 Aug 2020 10:29:28 -0700 Message-ID: Subject: Re: Pseudoterminal terminology in POSIX To: mtk.manpages@gmail.com Content-Type: text/plain; charset="UTF-8" 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: "Joshua M. Clulow via Libc-alpha" Reply-To: "Joshua M. Clulow" Cc: Florian Weimer , linux-man , libc-alpha , Larry Dwyer , Andrew Josey , austin-group-l@opengroup.org, Elliot Hughes , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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(), "/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. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org