Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp898254pxb; Wed, 13 Jan 2021 19:56:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJyWPsSxaxtIZX/GmL8r2j8STNrWBvAcBled+grNq4lolWMfim1BEx3GzRPebu2+L2lYtMdi X-Received: by 2002:a05:6402:2683:: with SMTP id w3mr4190231edd.378.1610596566591; Wed, 13 Jan 2021 19:56:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610596566; cv=none; d=google.com; s=arc-20160816; b=D9R9UR85aNloP2B801VEfC4SnRRRk8Kgp/7hRBGxmt9Ly1cQyDAPKeX5HqJmF1C3Xi zO8uU81FepKFDkA1z5nEhEMunosfKCnNDIQar+5Wl+bnM80019e4hIY8ANQoCVNzRBJP rYrwBDm87XFp9JRb2TJGRbcwRbICtcKokufzPTtcOCgjnJG6p43EbcipWWuqvw+0TmTu TfaqfnEt7MkbGsNmQVOJHM0jNO4+VwBItWpxnjSL+2POezlBgwChH3OrGlqVG0SZagVd Nw3SlP97L5iZpFo4J/iHyhgqi/Tzwy2nwyLo0GiY8HCKupdRD80NOmjTLNGpJfSZBZ7z z0XQ== 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=KOYVjFjEPLHe4g/Xv2gq0Q5D7ATBKeqZQ+I2UWT4FLk=; b=uo0LwO1DCRHl93LjyNJY2AHYBJK7zDLBKdc4wTkLJzIUQxjsKkwTZ6QCwrlmNaAWHE wFtDpRxGz+YK0XVRHJUvAzNEutuXqN/prbpuCSt6vtx+xXMFgg1nqraXUuvQd71GGUeU 0tRH6zQSW0/vosjiS3UWq7GkICclOfwfDuIai1SfJfWDN5K9i6RFh3fzdSZ2ls55pAKg ZBWEDeb+csIzaCtgsptc1lnU58gJjt5JGhPzPsdjbKnuJWcO+/+2vH5LwaHERCjkdR1s gM2DlFOaylKVpviq/XK9OM+K9DQvyZkLuZnBo5VTN4uvjwvCA/XcJt0KIQU908jCGW0l lcgg== 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 c23si1952154edv.521.2021.01.13.19.55.43; Wed, 13 Jan 2021 19:56:06 -0800 (PST) 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 S1726081AbhANDyv (ORCPT + 99 others); Wed, 13 Jan 2021 22:54:51 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:42344 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726003AbhANDyu (ORCPT ); Wed, 13 Jan 2021 22:54:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 6503D22D2C; Wed, 13 Jan 2021 22:54:06 -0500 (EST) Date: Thu, 14 Jan 2021 14:54:04 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann cc: Linus Walleij , John Paul Adrian Glaubitz , Gerhard Pircher , Arnd Bergmann , Linux Kernel Mailing List , linux-m68k , Sparc kernel list , Linux-sh list Subject: New platforms: bring out your dead, was Re: Old platforms: bring out your dead In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Jan 2021, Arnd Bergmann wrote: > > It's usually one of two things that happened before a platform gets > deleted for good: > > * The platform port was (almost) exclusively done by one company > with a commercial interest in it, and the company shifts its priorities > for some reason (acquisition, bankruptcy, product cancellation, > accidentally laying off all competent developers, ...) that causes it to > stop working on it. Sometimes the previously paid maintainers > keep up their upstream position, but without someone pushing the > last missing bits into an official release, users are stuck on an old > BSP kernel. > Yes, that's the typical product life cycle. It presumes a short window of opportunity for sales (suggesting that demand is not organic). Most vendors like to avoid having to compete with their own prior product lines. Hence the constrained lifespan that we get from devices with out-of-tree Linux ports. AFAICS open source licenses cannot really prevent this (no matter how many freedoms the FSF would like to confer on people). However, consumer law could do it, if it were to disallow products which were not servicable. > * A platform port is done in the open and actually works for upstream > users, but over time the last active maintainers move on in their > lives. Complex platforms inevitably break when a treewide change > goes wrong, so we rely on users that are able to bisect and report > bugs when they happen. And without bug reports, breakage gets leveraged into deletion, using the bogus argument that "broken" code is proof of zero potential users. > After a platform has been broken for too long, even competent users > may decide to just give up and stay on their last working kernel. Some > of these platforms eventually recover when a new maintainer steps up > or someone discovers they depend on newer kernels for products, but > after a few years it's usually beyond repair. > So all a vendor has to do is make maintenance a bit too difficult for competent users e.g. by depriving them of access to existing documentation. It was only a few decades ago that every applicance you bought came with a printed circuit schematic. These days, every device you buy comes with built-in obsolescence and a customer lock-in strategy. > Arnd >