Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp3964286ybg; Sun, 7 Jun 2020 16:47:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcbC5g32lro+ip+DMJllIPfj9rtu/goiU0jFYeiomkOBPjac7ofaGdEvt7VdtdjrEDklsN X-Received: by 2002:a50:9f27:: with SMTP id b36mr18967982edf.211.1591573659866; Sun, 07 Jun 2020 16:47:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591573659; cv=none; d=google.com; s=arc-20160816; b=Hd4hREdT7mm05MnPe1Fpy3w1B701OqZIjOKNwxohz1QTQpGEC3ZVBxHsITiDhOyna+ VcAh9ZL/UsmPW0IWlZfKRF2Eue3pUoU44oIQ063IkqWaNveGnLUgSvKXniRIMVwYtWlc wZCcbMG62chXKnhRr+mxX/wj6fee04Cs1P+EpQaeSNIOGpYgq2J09BHyREP/feojIf5p 0HIg+U5w6p8UvLud9+LfAyQnwzXLKKSsXavRVS16mfFGA4CHagKVaNCtdj62Z0eOKulM 78U9sWste51t1q3Nsyqm6/gHPDdyMKoG/S6ELgnl1n60i9xYLMc9Q3FV0KjjsSinrkMT rt9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=fyk7wLqzUqs2n4HzKyKLu8bvk7r3XLl/LQd0/0ldCQQ=; b=psqPNsO8J6g9Vqzg+9PMP946sp2Tsvnrnsl2EZO/zojJsOZOb+x23VjBIXtbuFJkr8 aW3MfuhtCMleKBFtswFmurdz5/WMIpjZJ9ogv1og/3NOFMG3x1Pyq3s1JTQ9lJ44wF0d kDGcaZkvN9ydqMAM9xBX+I/maK4hbwiBMkdCMF5nkqScoBmopioVcWBFeZ2HQwQSeh1j OG0ux9gCd5jC29FVNyUC9jDi+kvOXGTtyZsUOxahfq8YmufWU9Fch8rzsr9PwUqS0aXA 0ikLbedzw07vvKQHaPzMqtppCwRgEcIMmPbY2CKF3l6TY/wR9J4dbUCX1cPBHOXyPuPU koOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s12si6785847ejx.234.2020.06.07.16.47.15; Sun, 07 Jun 2020 16:47:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727982AbgFGXpf (ORCPT + 99 others); Sun, 7 Jun 2020 19:45:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727914AbgFGXpf (ORCPT ); Sun, 7 Jun 2020 19:45:35 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37DF0C061A0E; Sun, 7 Jun 2020 16:45:35 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 44FBC12738C25; Sun, 7 Jun 2020 16:45:33 -0700 (PDT) Date: Sun, 07 Jun 2020 16:45:32 -0700 (PDT) Message-Id: <20200607.164532.964293508393444353.davem@davemloft.net> To: stephen@networkplumber.org Cc: o.rempel@pengutronix.de, andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com, kuba@kernel.org, corbet@lwn.net, mkubecek@suse.cz, linville@tuxdriver.com, david@protonic.nl, kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux@armlinux.org.uk, mkl@pengutronix.de, marex@denx.de, christian.herber@nxp.com, amitc@mellanox.com, petrm@mellanox.com Subject: Re: [PATCH ethtool v1] netlink: add master/slave configuration support From: David Miller In-Reply-To: <20200607153019.3c8d6650@hermes.lan> References: <20200526091025.25243-1-o.rempel@pengutronix.de> <20200607153019.3c8d6650@hermes.lan> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 07 Jun 2020 16:45:33 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Stephen Hemminger Date: Sun, 7 Jun 2020 15:30:19 -0700 > Open source projects have been working hard to remove the terms master and slave > in API's and documentation. Apparently, Linux hasn't gotten the message. > It would make sense not to introduce new instances. Would you also be against, for example, the use of the terminology expressing the "death" of allocated registers in a compiler backend, for example? How far do you plan take this resistence of terminology when it clearly has a well defined usage and meaning in a specific technical realm which is entirely disconnected to what the terms might imply, meaning wise, in other realms? And if you are going to say not to use this terminology, you must suggest a reasonable (and I do mean _reasonable_) well understood and _specific_ replacement. Thank you.