From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Tue, 11 Sep 2018 13:53:40 +0200 Message-ID: To: Linus Walleij Content-Type: text/plain; charset="UTF-8" Cc: ksummit , Lukasz Majewski , Jonas Jensen , Alexander Sverdlin Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Deprecation / Removal of old hardware support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Sep 11, 2018 at 10:37 AM Linus Walleij wrote: > > Including Alexander Sverdlin, Lukasz Majewski and Jonas > Jensen here, they may or may not be able to share some of > their industrial IoT experience. (Contract terms with vendors > may make it necessary to stay silent sometimes.) Thanks > On Mon, Sep 10, 2018 at 11:41 PM Arnd Bergmann wrote: > > On Mon, Sep 10, 2018 at 5:35 PM Linus Walleij wrote: > > > > My ARMv4 is another example, but I can point at new devices > > > beging deployed as we speak, using that ISA, even though it is > > > from 1999. So it has many active users (and maintainers). > > > > Note that even though gcc is dropping ARMv4 support from new > > compilers, you can still use old toolchains, and there are tricks to > > make ARMv4T binary code work on ARMv4. However, if gcc > > ever stops supporting ARMv4T, this becomes a problem. My guess > > is that will take another 10 years though, and we might have > > removed some or all of the individual ARMv4 platforms by then. > > ARMv4 is becoming a trouble, not that it is hard to maintain, > actually we're on top of things there. The problem is that among > the FA526 systems from Faraday and the ARMv4T in EP93xx > there are very serious IoT deployments that have been going > on for soon 15 years and continuing. > > New MOXA ART ARMv4 FA526 systems are being deployed > in buildings across the planet as we speak. They just replaced > one in the office block where I sit, that is how I got to know. > > These are mostly for ventilation and > similar systems but also heavy duty from Liebherr controlling > unspecified hydraulic systems. The ventilation systems are > definately Internet-connected, I don't know about the others. > > These pose an increasing security threat, and for that reason > I personally feel it is irresponsible to remove the option to > create new kernels and upgrade these devices. I think it's likely that each of those platforms will get removed eventually, but we probably need to get better about documenting the constraints when we add a platform so we have a chance to find out if there are remaining users when it gets in the way 10 or 15 years later. One common trick is to find something that is known to have been broken for years as a proof that nobody cares about it in mainline (we try not to break things intentionally but after years of untested cleanup patches, something is likely to break eventually). This of course prevents you from upgrading kernels only every few years to the latest LTS version. Generally speaking, you always have a mix of two models in (good) products: you provide upgrades based on the latest kernels as long as it makes sense, but eventually you settle on some stable/lts/slts version that hopefully gives you security updates to the end of the expected life of the hardware, with otherwise minimal changes. Ideally we'd coordinate between kernel developers and downstream users here, so we can do our best to keep a platform alive up to a particular release that then becomes the base for the SLTS release to last the remaining hardware life after users are no longer planning to upgrade kernel versions. This again breaks down when you have the next Spectre or y2038 type event that forces everyone to upgrade. I wonder if we can assume that there is a natural limit of 18-20 years between such events that prevents people from running really old software in a safe way ;-) > I think for depreciation one has to be aware that some archs > used in IoT deployments have life cycles of 20-30 or more years, > whereas some tablet or handset SoCs may be something like > 5 years maximum before maintainers get annoyed that you > even use them. If you have specific examples for the 20-30 year deployment that you know is running Linux on ARM9, please point me to pictures that I can include them in my y2038 presentation. Arnd