Linux Set To Shed Nearly 500k Lines Of Code By Dropping Old CPUs

[phoronix]

Phoronix: Linux Set To Shed Nearly 500k Lines Of Code By Dropping Old CPUs

As expected, the Linux 4.17 kernel will move ahead with dropping support for older/unmaintained CPU architectures...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.17-Gutting-Old-CPUs

[Adarion]

TBH I haven't even heard of some of those, but it's still sad to see support for any kind of HW go. This broad architecture support is a real strength of Linux (and FOSS in general). You can always use some older HW or something more exotic for your purposes.
I remember havin read about Blackfin, and to me it feels like it's not so long ago that Linux was ported to Blackfin. Now it's already called obsolete? And code that is not active at runtime doesn't drag down others. Of course, you need maintainers to keep the code compilable and working.

Otoh. I don't know what "ported" actually means in these cases. Maybe some architectures there had virtually no userland and just the kernel would boot and one might not even have a real shell. In that case use is so limited it would probably be okay to drop the code.

[uid313]

Maybe users of all these legacy architectures can transition to ARM or RISC-V?

[GruenSein]

It is not like Linux will not work on these architectures anymore. It simply means that the latest kernels will not be compatible. One can always keep using older revisions. As there is appartently no to very little development going on with these platforms, that might be enough for their use cases.

[cb88]

Maybe users of all these legacy architectures can transition to ARM or RISC-V?

It's more like there aren't any users of these architectures anymore... well I think Tilera would be an exception not sure why they are dropping them as those are still produced as far as I know by Mellanox which bought EZChip and therefore Tilera.

They are definitely actively sold in high end routers from MikroTik also...

[paulpach]

And code that is not active at runtime doesn't drag down others.

It drags down developers. Say they are working on virtual memory or cpu scheduler. This code might need to be updated just so that it compiles. Sometimes a change can break this code so you end up with broken code in the stable release which is arguably worse than not having it at all.

[Dawn]

It's more like there aren't any users of these architectures anymore... well I think Tilera would be an exception not sure why they are dropping them as those are still produced as far as I know by Mellanox which bought EZChip and therefore Tilera.

They are definitely actively sold in high end routers from MikroTik also...

M32R, Blackfin, FR-V, and Hexagon are most assuredly still used - just mostly with RTOS's, not Linux.

Tilera is still shipped by Mikrotik but is effectively a dead end - it's been replaced by the ARM-based BlueField family.

[pcxmac]

Tminus minus 500k lines of code till kernel 5.0

[gamerk2]

It drags down developers. Say they are working on virtual memory or cpu scheduler. This code might need to be updated just so that it compiles. Sometimes a change can break this code so you end up with broken code in the stable release which is arguably worse than not having it at all.

Which is why I argue in this particular area of kernel design, Microsoft was right. The Kernel shouldn't care about architecture specific code, it should all be handled externally.

[starshipeleven]

Which is why I argue in this particular area of kernel design, Microsoft was right. The Kernel shouldn't care about architecture specific code, it should all be handled externally.

Since when Microsoft has any interesting thing to say about community-developed multi-arch kernels again?

Also, keeping everything unified (either at code or repo level) means that everyone shares the performance improvements, which is one of the main selling points of opensource. If all was neatly compartimentalized so that whatever module you write has 0 effect on anything else, then there would be very little cooperation and mutual improvement.

Microsoft has a proprietary product they DO NOT want third parties to touch, so it makes sense to make everything as compartimentalized as possible so that third parties can extend it without having to know anything about the kernel.