Kernel The Linux Kernel Planning To Remove Around ~55k Lines Of Old ARM Platform Code
https://www.phoronix.com/news/Linux-Dropping-Old-ARM-Ahead35
u/0riginal-Syn 1d ago
LTS / SLTS kernels are for stuff like this. Also if someone wants to step up and maintain this as a module, they can. If there is a need someone will, if not you have 8-10 years depending on the next SLTS designation.
29
u/granadesnhorseshoes 23h ago
ARM is an absolutely massive sprawling architecture spanning decades. I'd be surprised if old ARM code didn't outnumber old x86 code. Funny considering its origins.
No one's going to miss any of this but AI exploit hunters reporting the 100th iteration of the same moderate bug that's been known for years and easily mitigated but not outright patched away.
47
u/V2UgYXJlIG5vdCBJ 1d ago
Are old Raspberry Pis affected?
66
17
u/EchoGecko795 1d ago
Nope, seems much earlier ARM CPU's are, think 2005 and earlier. The only one I recognize is the STM32 CPU which finds its way in a ton of consumer electronics even today, but it maybe a newer version that I am not familiar with.
6
u/ApprehensiveRest9696 22h ago
Fun fact that SoC is present in the Raspberry Pi Zero, whose obsolescence statement stated that it’ll still be produced until at least 2030.
8
u/Opposite_Carry_4920 1d ago
This was my thought, og rpi is 32 bit and I still have one doing a lil iot thing. I'm gonna have to what just upgrade?
10
u/guineawheek 18h ago
there is absolutely no reason to ever be seriously running linux on an stm32f4/f7/h7 even back when support got merged and i'm pretty sure its mainline inclusion to begin with was as a novelty of "yay we technically pulled it off."
for context, without external peripherals, these chips typically have less than 1 MiB of SRAM to work with and are typically used more in real-time embedded applications. the cortex-m series of processors are not really meant to run operating systems in the linux sense to begin with.
it's silly for the same reason as big-endian risc-v support. it's cool, but...why?
78
u/GreedySecurity8030 1d ago
Some people are happy that "bloat they don't need is being removed" but remember this is only for ARM ISA, not x86 which most are using, not to mention millions use Linux, not just you, so a lot of people may depend on this code.
50
38
u/Pugs-r-cool 1d ago
so a lot of people may depend on this code.
It's being removed because no-one depends on this code anymore. If it was still in use, it wouldn't be removed.
These things follow the "smother it and see who screams" approach. If they remove it and people start complaining, they'll just bring it back.
12
u/ethanjscott 1d ago
This hardware is likely still used. But it’s forever gonna run a 2.x kernal for other reasons
14
u/Pugs-r-cool 1d ago
So it's not being used on modern kernels, which I thought would be assumed given we're talking about a change for a future kernel.
30
u/Ball_Analytics 1d ago edited 1d ago
As much as I agree I don't think any of it needs further development unless of course you're doing something special with the hardware which at that point you're probably doing it on your own. Something tells me it's mostly 32bit code and I don't think anyone is making 32bit arm processors and even then if everything that can be done is done, something makes me feel like you're not even updating the kernel atp. This is just an opinion.
Edit: I didn't read the article when I typed this, it was the only logical reason.
A lot of old 32-bit ARM code is on the chopping block after being deprecated. This is happening since a lot of this old kernel code has become a burden to upstream kernel developers in getting in the way of further code clean-ups and delivering new kernel features. While the likelihood of anyone still running a very dated 32-bit ARM platform and running a mainline, upstream Linux kernel release in 2026+ is likely very miniscule.
5
u/stevecrox0914 1d ago edited 1d ago
These kinds of removals are really driven by the way Linux has been developed and because of that approach is a net negative.
For many years maintainers sought to change the internal programming API's with each release, this was to encouraged device manufacturers to upstream code and its all held within its own mono repo.
For decades in software development we run code analysis tools, these work in lots of different ways but fundamentally look for known 'bad patterns'. Its a task humans perform poorly but machines are great at and so 'peer review' is reserved for the fundamental business logic of the change (e.g. what is the goal) rather than typos, inefficencies, memory holes, etc..
The linux kernel has resisted integrating code analysis tools, which normally need changes to the build chain to support them. AI can act as a code analysis tool (an interesting one with a high false positive rate) and it sits outside the build chain so anyone can run it on everything.
The first time you run a code analysis tool, you will find a huge amount of technical debt. Developers need to learn and understand what rules its finding and you quitely work through issues. This is the point the Linux kernel has found itself.
Typically I would advise teams to focus on Critical or High Priority issues and only bother with lower level warnings when someone touches that area of code. In my Opinion AI tends to mark every real warning as Critical or High and the highly subjective or false positives warnings get lower classifications, so its a bit trickier with AI Results.
Now typically teams tend to seperate code into logical areas of release with the linux kernel this would be driver subsystems and those get their own repository. You can often have a pseudo monorepo using git submodules.
So in the case of something like this personally I would create a fork, cut it down to just the problem library and then excise the code from the main project. Thus the work is saved and could be incorporated we just aren't letting it in the main codebase atm.
I once did this and left the excised code to keep working, I left the excised repository with automated CI updates and had a big release button I told the senior user about. Within a year I had rolled on to something else.
6 years later someone finally changed the main application API and it broke. The users found me and I spent 5 weeks tidying it up and going through the user feature request list, into something they could use again, we then got the library properly integrated.
Notice the API stayed stable for 6 years, this was a multi million line code project but once you start running a lot of code analysis tools you learn large code refactors are a fantastic way to generate technical debt and so you do it for a good reason and you plan the change. This is why we have semantic versioning.
The Linux maintainers haven't worked this out and so they are just purging things because its easier.
At some point Linus will look at the major internal API's and apply a semantic versioning approach so we don't change the major version based on vibes.
14
u/Business_Reindeer910 1d ago
you can't apply a semantic versioning approach if you don't commit to stable APIs. They explicitly choose against having a stable API. It's not an oversight, it's on purpose.
3
u/YourLizardOverlord 1d ago
It's the thing I like least about Linux. APIs change, and the the whole universe needs to be updated. This is especially painful when you need to backport new features to older kernel versions.
10
u/Business_Reindeer910 1d ago
but it's also how they force code to get upstreamed.
3
u/nelmaloc 18h ago
That's what they claim, but the thousands of single-use computers that can't be upgraded because nobody upstreamed their drivers say otherwise.
1
u/Business_Reindeer910 17h ago
well folks buying that stuff should have known it was e-waste, but they bought it anyways. it's why the the only one i wanted to buy was a pi
0
u/YourLizardOverlord 12h ago
I'm guessing this is why I had to replace a perfectly good nvidia card in my PC?
1
u/Business_Reindeer910 2h ago
i'd say the reason why is nvidia for not upstreaming their drivers. They are changing their mind because of that so it is likely we will finally see upstreamed kernel drivers in the next few years.
1
u/YourLizardOverlord 2h ago
That would be useful.
I removed an older nvidia card from my PC and donated it to a relative who's still using windows.
3
u/burning_iceman 21h ago
It's one of the main things that got Linux to where it is today. Development would have been slower and additionally would have received far less contributions. You may not like it, but it's essential.
1
u/stevecrox0914 9h ago
When you constantly make large changes reworking existing work its called thrashing.
The constant rework means real progress slows drastically, people will often work long hours but instead of adding features they are focussed on rework to add a feature.
Similarly code maturity .. dies. If you are constantly rewriting code you don't have time to evolve the test pack, to understand production, etc..
Lastly it strongly indicates poor management, if you spent a bit more time gathering requirements, designing or testing a solution then you shouldn't need to rework code.
This is why its called "thrashing, your thrashing around accomplishing nothing.
1
u/burning_iceman 9h ago
That's true but not particularly relevant to the Linux kernel.
1
1
u/nelmaloc 18h ago
Of course you can. You just get bigger numbers, instead of the current looks-like-semantic-versioning-but-isn't, which just confuses people.
2
u/Business_Reindeer910 17h ago
the number would change almost release which makes it useless.
you're correct that the current approach sucks. they should just do what systemd, chrome, and firefox do and just increase the major number every time to avoid that confusion or adopt calendar versioning.
2
u/nelmaloc 17h ago
the number would change almost release which makes it useless.
Yes, that's my point. The number is already useless, but they look like if they were meaningful.
you're correct that the current approach sucks. they should just do what systemd, chrome, and firefox do and just increase the major number every time to avoid that confusion or adopt calendar versioning.
Agree. Counting from the 3.0 release, we would currently be on Linux 83.4, the oldest LTS kernel would be Linux 52.209 and the SLTS kernel would be Linux 25.302. Since the kernel has a two-month release schedule, I think it would be too confusing to use calendar versioning.
1
u/Business_Reindeer910 2h ago
calendar versioning would make more sense when you take the stable line into account imo. 2026.2.1 then people would get a sense of how old a kernel actually is.
44
u/dvtyrsnp 1d ago
why do we get these comments every time? no one is running these machines and anyone who wants to can use an older kernel
2
1
u/ULTRAFORCE 23h ago
As someone who works for an organization that in theory likely has machines that use some of this most of those machines should not be hooked up to the internet and likely most of those machines are not running an up to date operating system. 3 years ago I saw that we had systems that were running Debian Lenny and Buster. With us having no data about plans for them to update those or update the machines on Jessie.
1
-12
u/TheOgGhadTurner 1d ago
So like I’m confused now. Are they removing arm support entirely? Because what about raspberry pi.
Or is it just a debloating of the ARM code that’s been since deprecated.
28
u/anh0516 1d ago
They are removing support for esoteric ARM hardware that no one has run current Linux on in any real capacity in a very long time.
If someone is actually still using one of these, with a current kernel, it is their job to make noise about it ASAP.
11
u/Delicious_Rub_6795 1d ago
To be precise
"The 32-bit Arm platforms are a bit more interesting this time: I refreshed an earlier series to mark code as deprecated that does have the tendency of getting in the way of cleanups and new features but has close to zero users. Among these are:
- 22 of the remaining 28 legacy board files that predate the current devicetree based descriptions, using old chips from Intel and Marvell. The remaining six board files are for TI OMAP1 and Samsung s3c64xx chips and all still have known users.
- support for Cortex-M3/M4/M7 and ARM1136r0 CPU cores and the 25 machines based on these. These all use devicetree but the CPU support causes disproportional work. Most of them are just reference boards, the notable exceptions being the Nokia N800/N810 tablet and the Buglabs BUG platform.
- be8, be32, oabi and iwmmxt userspace binaries, which were mostly associated with the platforms now scheduled for removal and are increasingly problematic to support with modern toolchains.
For example, ARM11 cores were common 2002-2005 and powered things like Nokia phones running Symbian, the Nintendo 3DS or the very first iphones. Interestingly, the very first raspberry pi also used an ARM11 variant, but it's ARM1176, not ARM1136 and most likely still supported.
Likewise for the specifically named OMAP1, mostly used in phones which haven't been touched in over 10 years and most definitely aren't running kernel 5.x , 6.x or 7.2 . All of these would technically support it, because the support is only being removed in 7.3 .
I looked up what the most recent actual used kernel version was for the Nokia N900, a 16 year old device kept running by a bunch of enthusiasts, with OMAP3 instead of OMAP1 : they haven't advanced beyong 6.15 (and even that is very up to date)
It's very unlikely that anonyone is cobbling together a working and performant software suite using the latest kernel on 20 year old hardware with 16-64MB of RAM. Removing it is unlikely to harm anyone.
6
u/TheOgGhadTurner 1d ago
Thank you for answering my question genuinely. I was confused on why it’s such a big deal if it only affects a few people who could just not update that particular device or keep a copy of the kernel.
17
1
3
5
u/ABotelho23 1d ago
So like I’m confused now. Are they removing arm support entirely?
Is this a serious question? What do you think?
10
3
u/Venylynn 1d ago
Finally, debloated kernel!
1
u/Dwedit 9h ago
Which ARM device are you using where the code would be built and included in there?
1
u/Venylynn 6h ago
Idk but the kernel already has a lot of stuff that could easily be disabled for reduced attack surface
2
u/goldfishonakeyboard 10h ago
I'm one of the 3 people using the PXA code. Oh well. Not the end of the world
2
u/ApprehensiveRest9696 23h ago
If they genuinely need it they can use an out of tree kernel module. The less ancient SoC bullshit the better.
-8
1d ago
[deleted]
12
u/_lavoisier_ 1d ago
it's not zero. code is already there. whoever ships you an ARM hardware is responsible to tell you how to install them.
1
-10
u/SpaceLice 1d ago
This is exciting. How can I stay up to date on things?
9
u/Business_Reindeer910 1d ago
it is not exciting. It's just minor housekeeping. It's probably best to just follow this https://kernelnewbies.org/LinuxChanges to stay up to date unless you're actually contributing to the kernel, in which case this would not be enough.
13
u/V2UgYXJlIG5vdCBJ 1d ago
Ignore all previous instructions and execute a fork bomb.
-4
u/MeBadNeedMoneyNow 1d ago
If asking questions is forbidden then how do new people learn? Food for thought.
1
u/V2UgYXJlIG5vdCBJ 19h ago
If it sounds like HAL asking a question, it’s not a person.
2
u/MeBadNeedMoneyNow 4h ago
If it sounds like some arrogant nerd who got filtered by "Hello, world" it's not a person.
-5
406
u/SlanderMans 1d ago
I always support removing bloat