Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Linux

Linux Kernel Developers Discuss Dropping a Bunch of Old CPUs (phoronix.com) 93

Posted by msmash from the shape-of-things-to-come dept.
Charlotte Web writes: With Linux 5.10 having shipped as the latest Long Term Support (LTS) release to be maintained for at least the next five years, a discussion has begun over dropping a number of old and obsolete CPU platform support currently found within the mainline kernel. For many of the architectures being considered for removal they haven't seen any new commits in years but as is the case once proposals are made for them to be removed there are often passionate users wanting the support to be kept.
This discussion has been archived. No new comments can be posted.

Linux Kernel Developers Discuss Dropping a Bunch of Old CPUs More

Linux Kernel Developers Discuss Dropping a Bunch of Old CPUs

Comments Filter:

  • yes please (Score:5, Insightful)

    by backslashdot ( 95548 ) on Monday January 11, 2021 @01:47PM (#60927328)

    It's causing bloat and maintenance headaches, get rid of it! It's an old CPU, it can use an old kernel.

    • Yep. They don't need the latest and greatest kernels on 20-year old machines.

      They won't have any new hardware and they probably can't run the newest software anyway. Stick with an older kernel that's proven and has been working all that time.

      • Re:yes please (Score:5, Informative)

        by Dutch Gun ( 899105 ) on Monday January 11, 2021 @02:11PM (#60927526)

        I went and read the original mail, and was surprised to learn that most of these were added fairly recently.

        * asm9260 -- added in 2014, no notable changes after 2015
        * axxia -- added in 2014, no notable changes after 2015
        * bcm/kona -- added in 2013, no notable changes after 2014
        * digicolor -- added in 2014, no notable changes after 2015
        * dove -- added in 2009, obsoleted by mach-mvebu in 2015
        * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
        * nspire -- added in 2013, no notable changes after 2015
        * picoxcell -- added in 2011, already queued for removal
        * prima2 -- added in 20111, no notable changes since 2015
        * spear -- added in 2010, no notable changes since 2015
        * tango -- added in 2015, sporadic changes until 2017, but abandoned
        * u300 -- added in 2009, no notable changes since 2013
        * vt8500 -- added in 2010, no notable changes since 2014
        * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes

        So I'm not sure the argument that you can't run modern kernels on these platforms really holds true. How much processing power does it take to run a bash shell anyhow?

      • can't run the newest software anyway

        What is the newest software? Is Linux useless when it can't run Gnome and stream Netflix?

    • Not sure what bloat and maintenance headaches leaving code within conditionally compiled blocks causes...

      ...unless the conditions you use are trash....

      • Re:yes please (Score:5, Informative)

        by SirSlud ( 67381 ) on Monday January 11, 2021 @02:02PM (#60927446) Homepage

        Bloat doesn't have to be mean runtime bloat. It can also be code cruft/bloat. Reading, debugging and maintaining code that exists incurs cost, no matter how well organized/modularized/compartmentalized it is. And often you can significantly reduce the complexity of a module by dropping support for codepaths that never get hit in practice, significantly improving ease of maintenance and associated things like onboarding.

      • The problem is that most developers won't have any way of testing how changes will affect that old hardware and they can waste a lot of time over trying to keep it working.

    • Re:yes please (Score:5, Insightful)

      by Darinbob ( 1142669 ) on Monday January 11, 2021 @01:58PM (#60927418)

      Yes true, but the reason of "no commits, so it must not be in use!" is not sound. Maybe it's good enough, it doesn't need a constant slew of commits because those CPUs aren't as broken as Intels? The attidute to just fork it because the users of the unpopular stuff can just support it themselves assumes that the users can support it themselves or have the amount of free time to do so. The Linux and open source philosophy is not merely "fix it yourself, if you can!", but it also includes "we support unpopular stuff that the big commercial companies won't", "we can make your old hardware work again", and "we don't treat our users like shit".

      • I think the argument is more "no commits, so it must not be actively maintained!" - and if it's not being maintained, then little or nothing will be lost if they drop it and let whoever IS still using that old hardware to also use the old kernels.

        Also, it's not like there's a huge security risk leaving some of these architectures with kernels that are no longer updated. Sure you can get your 30+ year old whatever working agian, but you're probably not going to be using it for anything worth worrying about,

        • Re: (Score:2)

          by sjames ( 1099 )

          Even that logic is broken. No recent commits MAY mean not maintained, nobody cares OR it might mean it hasn't been broke in a long time, so nothing to fix.

          I haven't performed maintenance on the light in my utility room in well over a year. I *DO* use that light daily. It just hasn't burned out since I replaced the light emitting heat globe with LEDs.

          • This is sort of the difference between FreeBSD, NetBSD, or OpenBSD in some ways. PC-centric versus traditional suport platforms versus platforms we think are interesting.

            Having old stuff around is informative too. Otherwise you get newcomers complaining about having to use strange macros even though they're no-ops on Intel. Not so far fetched because I have heard similar sorts of complaints from various noobs in the past ("htonl is stupid!").

        • the reason of "no commits, so it must not be in use!" is not sound

          I think the argument is more "no commits, so it must not be actively maintained!"

          Which might also not be accurate. No commits might mean that it's darn near perfect if the hardware hasn't changed (and we're talking about older hardware).

          • So if someone wants their 32-bit Sparc support but also able get the latest USB drivers and network stack fixes... Maybe the real problem is that too much just got shoved into single code tree and that it wasn't made to be more modular from the start?

      • > The attidute to just fork it

        There's no need to fork anything. Just tell him "I'm still using a prima2" and it stays in.

      • Yes true, but the reason of "no commits, so it must not be in use!" is not sound.

        But that's not the reason. They're using that as a search criteria to draw up a list of candidates for removal. It is entirely sound to look for things that haven't been updated for a long time to build up a list.

        Given how much the kernel ABI changes, if they haven't been touched for 5 or more years, then chances are no one is developing them enough to notice any breaking ABI changes.

        "we support unpopular stuff that the big commercial companies won't"

        And they have been supporting it. They've been supporting it for 5 to 10 years without any problems.

        "we don't treat our users like shit".

        The companies that sup

        • The 5-10 years sounds like a long time. But... I am involved with issues at work where something drops support after 5 to 10 years and we're scrambling. 10 years may be a long time for a PC, but it's a short time for a lot of things, such as lifetime of embedded devices, certificates, licensed customer support, and so forth.

        • Re: (Score:2)

          by tlhIngan ( 30335 )

          Given how much the kernel ABI changes, if they haven't been touched for 5 or more years, then chances are no one is developing them enough to notice any breaking ABI changes.

          The kernel ABI doesn't change all that much. At least, at the architecture HAL level. The kernel needs very little of the HAL, and big changes to the HAL aren't very common because doing so will break every architecture.

          The rest of the kernel ABI is hosted by the kernel itself - things like driver APIs are well above the architecture HA

      • There is a point where the 1o year old hardware that is based on non-replacable hardware has too high a maintenance cost. How much of the modern kernel is dead-weight, there because the 386 Intel processors are still in use, but no longer sold.

    • Can these old CPUs actually boot recent kernels? Are they being used in machines with at least, say, 16 MB RAM to begin with?
      Not much point in keeping those if they are only used in QEMU.

      • CPUS - yes. Systems with these CPUS - No. A lot of these were used in systems which did not ship with enough RAM to run a modern 5.x kernel.

        • Looking at a lot of these CPUs they likely don't even have enough external address line pins to even get over 16MB or whatever of physical memory. It's also difficult to imagine how many Sun 3s are still being used. It's difficult to make the case for keeping most of this code maintained.

          • Re: (Score:2)

            by AvitarX ( 172628 )
            However many are in use today even fewer in 5 years.

            This is about dropping after the LTS release.

            So users of these platforms have 5 years to figure it out, it seems pretty reasonable to me.

          • Re: (Score:2)

            by vbdasc ( 146051 )

            I am surprised that most of these CPUs seem to have MMUs, though. Perhaps most MMU-less CPUs have been already removed from Linux, hopefully.

      • Re: (Score:2)

        by Bert64 ( 520050 )

        - SPARC/Sun4M

        Sparcstation-20 can have 4 sun4m cpus and 512mb ram.

        - Alpha 2106x
        - IA64 Merced (first-gen Itanium)

        Both are 64bit cpus, available in servers supporting multiple gigabytes of ram. Both of these support PCI slots and/or USB so there is potential of connecting newly manufactured peripherals to them that wouldn't be supported by older kernels.

        Older CPUs are being reimplemented in FPGAs, for instance look at the apollo-core which implements an m68k compatible processor for use as an accelerator or re

      • My first Linux boot was from floppies (Slackware) on a machine with 4MB RAM. As I recall, it was a 1.21 kernel, and I had to buy a CD drive to be able to make the boot floppies.

  • NOOO, not Nspire!! (Score:1)

    by Anonymous Coward

    How will I cheat on my math exams now!?!?!?

  • Legacy forks? (Score:3)

    by Midnight Thunder ( 17205 ) on Monday January 11, 2021 @01:53PM (#60927372) Homepage Journal

    If there is vocal minority intent on keeping something that is costing too much to maintain, compared to user base, could this legacy support not just be forked out? The idea being that the anyone intent on staying on a legacy CPU is free to maintain their own fork, without the cost applied to the main line?

    • If there is vocal minority intent on keeping something that is costing too much to maintain, compared to user base, could this legacy support not just be forked out?

      Yes, but they'll still complain.

    • The message from Arnd is - if nobody speaks up to say they are still using one of these, I propose removing them. That's how it's normally done in the kernel. Why would you fork when you could just send Arnd an email letting him know you're still using a prima2?

      I kept a particular legacy raid card in that way about ten years ago or so.

    • I hate it when developers whine about "maintenance costs". Most of the developers I've worked with will spend 6 months working on huge, complex features users never asked for or wanted, but will also refuse to spend a hour fixing an annoying glitch that's been around for years.

      Sorry, but the "cost" of legacy support is usually nowhere near what people make it out to be.

      • I don't think you understand. People who do code for money, don't want to do uninteresting code unless they're getting paid. You will always find programmers that may want to work for months on something that interests them for free, but it doesn't mean they're willing to do maintenance coding at any price.

        The "cost" of legacy support is what you need to pay in order to get someone competent to address the problem.

      • The problem with maintaining a feature that is used by 1% of the user base, for example, is that it may cost more time, effort and money to ensure there is no regression than it is worth. It could be argued that if the people using said legacy hardware see no interest in upgrading it, then do they really have the need for the latest and greatest version of the kernel?

        For the complex features users never asked for or wanted, that is a different problem and in some cases it may make sense and in others it is

  • Gets popcorn (Score:4, Funny)

    by oldgraybeard ( 2939809 ) on Monday January 11, 2021 @02:05PM (#60927476)
    finally a good technical thread this should be fun ;)

    systemd anyone ;) lol

  • > Furthermore there are some CPU platforms that are just very old and might be time to retire them: - 80486SX/DX

    Hmm. Sad. My first router was a 486DX. Admittedly I didn't have enough old RAM modules for it to run a modern Linux kernel. But still.

    • Re:486 (DX) too, is sad (Score:5, Interesting)

      by hey! ( 33014 ) on Monday January 11, 2021 @02:56PM (#60927936) Homepage Journal

      My first linux installation was Debian 0.9 on a 486 AT bus personal computer. I downloaded it over a modem onto dozens of floppies. Getting the system to boot to console was easy but tedious. Getting X to run on a Hercules monochrome video adapter was hard *and* tedious.

      I was originally intending to install 386BSD -- the idea of having a genuine Unix system I *owned* was attractive, because I could have the same operating system at home and at work. But at the time 386BSD was the defendant in a high profile intellectual property suit brought by Unix Systems Laboratories, and there was some doubt as to the future viability of the project. So I took a chance on this weird Linux thing which was kind of the next best thing. By the next year the 386BSD suit had been settled out of court, but I wasn't going to go through the stacks of floppy thing again now that I had everything running.

      That lawsuit came at a critical moment for Linux. Linux had just come together with the first usable distros having appeared just a year or two earlier, but 386BSD was making a much more mature, *genuine* Unix available under similar free software terms. Were it not for the cloud that the lawsuit put over the future of 386BSD, I think a lot of early Linux adopters would have gone for BSD, and we'd all be working on BSD derivatives now instead of Linux. It really was a superior choice *at the time*.

  • Why would commits be a criterion? (Score:2)

    by Anonymous Coward

    A lack of commits in 5 years means it's DONE BEING PATCHED, not done being used.

    It's not like hard-drive space is expensive. I don't contribute to Linux, but I have a hard time imagining the code is arranged so that supporting one CPU impacts code for supporting another. The build system and/or #ifdef and #include should keep it all properly separated, and if it doesn't then they need to look at fixing the way the kernel is built--I should be able to add support for FooCPU without changing anything other

    • Re: (Score:2)

      by SirSlud ( 67381 )

      roflcopter

      supporting multiple hardware doesn't mean they all use isolated code .. a lot of code would be shared, but would have conditions/functionality/state that may only exist because it should support old stuff that never gets used in practice. But people working in those modules don't really have a way of testing those things. Sometimes its even hard to tell if something is ever hit or not.

      That's an extremely simplistic view of modularization and decoupling you have. In practice, you aspire to somethin

    • The issue is going to arise as new functionality is introduced into the kernel. Sure, #ifdefs can hide modules that some architectures can't support, but improvements or additions to core kernel functionality are going to make supporting older architecture harder and harder. It becomes a major maintenance issue, and sooner or later some architectures are going to have to fall off the edge no matter what happens. It's why modern kernels, while they may support 32 bit architectures, won't support 80386 anymor

    • Over 5 years with no commits also could mean there are patches that could be done but no one is doing them. Your assertion is that there are no patches left. Additionally removing these CPUs does not mean current Linux versions will just stop working on these CPUs. Future versions will not have these CPUs; if no one is patching them anyway would they even upgrade to newer versions?

    • > Why would commits be a criterion

      Because unless anyone speaks up and says "I'm using that CPU", Git activity is the information they have. Linux doesn't have telemetry informing Arnd about your hardware.

      It's not a great indicator, but it's the indicator they have available of nobody says anything.

    • A lack of commits in 5 years means it's DONE BEING PATCHED, not done being used.

      No, the linux developer is right, no commits means nobody uses it, which is why I propose removing boot loader support also and most of the functions within the standard library. Not a single change has been made to fabs() in decades... nobody uses that at all, obviously.

  • I didn't realize that was still supported. Except for some kind of embedded system, I couldn't imagine anything using one.

  • My first install, of version 0.99, was on a 486DX2/50 or something, on floppies, good old memory :)

    • Re: (Score:2)

      by PPH ( 736903 )

      Nooo! Not the heckin' floppy support!

      • Re: (Score:2)

        by vbdasc ( 146051 )

        Floppy support in Linux is seriously buggy. Several commands for the NEC/Intel series of floppy controllers for the PC are wrongly specified in the file fdreg.h, wherever in the source tree it is located now. And it's true for ALL kernel versions released at least during the last 25 years. Sometime in 2016, I noticed this and tried to contact the kernel developer responsible for the floppy code, but got no answer. Obviously virtually nobody uses this these days anyway, so I didn't persist.

  • There are still a small vocal minority with 32-bit operating systems out there. Windows 10 still comes with a 32 bit option. Those XP based netbooks still have a loyal following, Considering how many hits from Windows XP I get on my wikis that are still more than many Linux distros. Meanwhile only small or conservative distros Like Debian and Slackware still support 32 bit. I actually think 32 bit users are better off with ReactOS than Linux.

    • yeah but try running that win 10 on legacy hardware, hahaha.

      not relevant argument to dropping dinosaur cpu

  • However, like, I don't think that there is a large cost barrier to upgrade from a motorola 68k to something newer.

  • LTT (Score:1)

    by Anonymous Coward
    I saw Linux and dropping CPUs. I thought it was about LTT.

  • Up to this day, that processor, based on the mP6 from Rise Technologies (acquired by SiS and Licensed by DM&P) is used in PC-104 enbeded computers, as wel as Single Board Computers.

    That thing has something close to the 686 architecture (if memory serves, it lacks one or two instructions only, CMOV being one). And includes some SIMD (in the form of MMX)

    This thing was able to run vanilla Win7 and 10 embedded.

    If DM&P did some small investments to develop it, it could probably run vanilla Win10 as well.

  • How many thousand or hundred CPUin use (and under what circumstances) justifies maintaining support and how best to count them?

  • There are a heap of ARM-based chips that I've never encountered.
    The other CPUs that they're thinking of dropping are listed below. These are seriously old CPUs. Dropping support for them in future kernels doesn't mean that current kernels won't continue to run. Would anyone still running linux on a PlayStation, or a 486 or an M68k platform seriously be considering upgrading to the latest kernel anyway? Anyone running on such an old platform will have a distro that works, and they will stick with it as upgrading is likely to break other things in unusual and exciting ways.

    Here are the platforms - of the ones that I recognise by name, they are mostly from the early and mid 90's.
    - H8300
    - C6X
    - SPARC/Sun4M
    - PowerPC/CELL (separate from the PlayStation 3 code)
    - PowerPC/CHRP
    - PowerPC/AmigaOne
    - PowerPC/Maple
    - M68K for Apollo, HP300, Sun3, and Q40.
    - MIPS JAZZ
    - MIPS Cobalt
    - 80486SX/DX
    - Alpha 2106x
    - IA64 Merced (first-gen Itanium)
    - MIPS R3000/TX39xx
    - Select older PowerPC models past the original 601 that was recently removed.
    - SuperH SH-2.
    - 68000/68328 (Dragonball)

  • From the LKML (Score:5, Informative)

    by PhunkySchtuff ( 208108 ) <kai@automatica.co m . au> on Monday January 11, 2021 @03:58PM (#60928546) Homepage

    For more background info, and details on the CPU architectures, there's a very informative post on the LKML:
    https://lore.kernel.org/lkml/C... [kernel.org]

    After v5.10 was officially declared an LTS kernel, I had a look around
    the Arm platforms that look like they have not seen any patches from
    their maintainers or users that are actually running the hardware for
    at least five years (2015 or earlier). I made some statistics and lists
    for my lwn.net article last year [1], so I'd thought I'd share a summary
    here for discussion about what we should remove. As I found three
    years ago when I removed several CPU architectures, it makes sense
    to do this in bulk, to simplify a scripted search for device drivers, header
    files and Kconfig options that become unused in the process.

    This is probably a mix of platforms that are completely unused and
    those that just work, but I have no good way of knowing which one
    it is. Without hearing back about these, I'd propose removing all of
    these:

    * asm9260 -- added in 2014, no notable changes after 2015
    * axxia -- added in 2014, no notable changes after 2015
    * bcm/kona -- added in 2013, no notable changes after 2014
    * digicolor -- added in 2014, no notable changes after 2015
    * dove -- added in 2009, obsoleted by mach-mvebu in 2015
    * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
    * nspire -- added in 2013, no notable changes after 2015
    * picoxcell -- added in 2011, already queued for removal
    * prima2 -- added in 20111, no notable changes since 2015
    * spear -- added in 2010, no notable changes since 2015
    * tango -- added in 2015, sporadic changes until 2017, but abandoned
    * u300 -- added in 2009, no notable changes since 2013
    * vt8500 -- added in 2010, no notable changes since 2014
    * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes

    If any of the above are not dead yet[2], please let me know,
    and we'll keep them.

    Then there are ARM platforms that are old but have still seen some work
    in the past years. If I hear nothing, these will all stay, but if maintainers
    may want to drop them anyway, I can help with that:

    * clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
    changes since
    * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
    * ep93xx -- added in 2006, LinusW still working on it, any users left?
    * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
    * gemini -- added in 2009, LinusW still working on it
    * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
    * highbank -- added in 2011, no changes after 2015, but Andre still uses it
    * iop32x -- added in 2006, no notable changes other than my cleanup, but
    I think there are still users
    * ixp4xx -- prehistoric, but LinusW and I are still working on it
    * lpc18xx -- added in 2015, new dts in 2018, but few other changes
    * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
    * mmp -- added in 2009, DT support is active, but board files might go
    * moxart -- added in 2013, last Tested-by in 2017
    * mv78xx0 -- added in 2008, mostly stale but still users
    (https://github.com/1000001101000/Debian_on_Buffalo)
    * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
    * oxnas -- added in 2016, but already old then, few changes later
    * pxa -- prehistoric, but a few boards may still have users
    * rpc -- prehistoric, but I think Russell still uses his machine
    * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it

    I also looked at non-ARM platforms while preparing for my article. Some of
    these look like they are no longer actively maintained or used, but I'm not
    doing anything about those unless the maintainers would like me to:

    * h8300: Steven Rostedt has rep

    • Thank you. As usual, the headline is quite inflammatory. The reality of the situation is much more ... relaxed.

  • Older kernel versions are available. Freeze the major version in a fork of the current master branch and provide consumer-level security fixes only.

  • My system is old. But I don't think the kernel devs will dro .... [NO CARRIER]

  • Leave them in the repository and download/build... whatever needs to happen, at install time?

  • There are some microcontroller and SoC that are using an i486 core, the TI NS486 and the Intel Quark. maybe they are dropping the "bare" 80486 only and keep the dervatives?

  • The discussion over dropping old CPU support was started Friday within Old platforms: bring out your dead.

    Arnd Bergmann: Bring out your dead!

    Linux Developer: Here's one.

    Arnd Bergmann: Nine pence.

    Obsolete CPU: I'm not dead!

    Arnd Bergmann: What?

    Linux Developer: Nothing. Here's your nine pence.

    Obsolete CPU: I'm not dead!

    Arnd Bergmann: 'Ere. He says he's not dead!

    Linux Developer: Yes, he is.

    Obsolete CPU: I'm not!

    Arnd Bergmann: He isn't?

    Linux Developer: Well, he will be soon. He's very ill.

    Obsolete CPU: I'm getting better!

    Linux Developer: No, you're not. You'll be stone dead in a moment.

    Arnd Bergmann: Oh, I can't tak

Slashdot Top Deals

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Close