Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1269162pxj; Wed, 19 May 2021 02:06:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzP/GSil31VCBbva+ezSeQ20hJjAX45EAFRCJ1pZO1jXSPvlP7n7c1zSx6Kj95g6eS5B8hD X-Received: by 2002:a05:6402:128f:: with SMTP id w15mr13324583edv.354.1621415166191; Wed, 19 May 2021 02:06:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621415166; cv=none; d=google.com; s=arc-20160816; b=du1onwMkWdHmIpf1rZ9XnS5ySUeOWYmyjTv7adZSN0laGtGp0+O/5PYypOU1a6qq84 SBKPxgJZDBLmtUiuUI7B9HMy6YC8C7B+UdIUVhp+r/foVqRGVc/hqtPZbAbubU8AVw53 JYWn5ijZsiF3y9vDIj3o1/gY5D6NGZPAHW0kyDojuy08hwtn4zxVc6Td/PRZIosQnr7G pKFWZmJxNtIkH3fXDvjC/MQCmwrnSyYbkdOPY54aTv3v5qwwoFsFvBSunFIem+TC+/SL 5NhbMZAf9xHi0aLRLXAjCCQC0PfZTsZ6t8sTeXwivCq9lMMkO3Xr0zhh+PxxckL0t3uE 4iqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=sAZ336VC1MSCUpdrKHtBkuuK3ADreKnCGVHr29eAQxc=; b=PQFBSuoantvLNh0btVeGtmE/0WM75DAy3O7y+ee+NAGXvQk7KZrgvZuHEHEv42uWqq ucw48EcombNHvvFhzU57CHL9HR2ZBxJU20zpzKO/sYo91xy6s6widCRbzQewfhQLZDev IFDR2p/FbYon3QYKRGhI9dhDq0Kdla2zGcOhCGchjLdntE3WVAn7xC0zXi/Pzq/JTJQl omwzcHUckQy0VirfLU8TP6ZWynUeLx6BtMMw7oSc8kWB5hkEYGBPeT3OpnUErUCHa+E4 QQ/77uhGLJakscNSjgyVNnSaMgXj9O/RhaVbe+ZScwFtbr8OH9z/z/n2fG9h4gR4+bg5 hP4A== 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 y17si2863424edw.191.2021.05.19.02.05.43; Wed, 19 May 2021 02:06:06 -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 S1344174AbhEQXFl (ORCPT + 99 others); Mon, 17 May 2021 19:05:41 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:38178 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233727AbhEQXFl (ORCPT ); Mon, 17 May 2021 19:05:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 5611D21F27; Mon, 17 May 2021 19:04:19 -0400 (EDT) Date: Tue, 18 May 2021 09:04:17 +1000 (AEST) From: Finn Thain To: Paul Gortmaker cc: Arnd Bergmann , netdev@vger.kernel.org, Arnd Bergmann , "Maciej W. Rozycki" , "David S. Miller" , Jakub Kicinski , Doug Berger , Florian Fainelli , Sam Creasey , Geert Uytterhoeven , Finn Thain , Christophe JAILLET , Andrew Lunn , Alexei Starovoitov , Eric Dumazet , Andrii Nakryiko , Bartosz Golaszewski , linux-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com Subject: Re: [RFC 00/13] [net-next] drivers/net/Space.c cleanup In-Reply-To: <20210517143805.GQ258772@windriver.com> Message-ID: References: <20210515221320.1255291-1-arnd@kernel.org> <20210517143805.GQ258772@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 May 2021, Paul Gortmaker wrote: > Leaving the more popular cards was a concession to making progress vs. > having the whole cleanup blocked by individuals who haven't yet realized > that using ancient hardware is best done (only done?) with ancient > kernels. > By extension, using ancient kernels is best done with ancient userland. And now the time has come to remove all the 'compat' nonsense. Oh, wait, all of that old software seems to be riddled with bugs and vulnerabilities. And who would have thought that all those developers writing new code for emulators and their users were holding up "progress"? > Maybe things are better now; people are putting more consideration to > the future of the kernel, rather than clinging to times long past? If you've been doing engineering for a while you'll start to notice a pattern: old designs that work get reused. That's partly why the latest silicon contains ancient logic blocks. When that changes, perhaps we can talk about "progress"...