I like the potential your comment has even though it's wrong on every point, it is interesting to go back and understand why 386 support was removed.
Since the days of 386 support, the kernel has only become much more modular and portable. It quite possibly supports more platforms and CPU architectures and families than any other OS ever written. Almost certainly true if you restrict it to a multitasking >= 32-bit OS with memory protection and virtual memory.
Many architectures and ports that have been removed or not merged were not due to being technically incapable of supporting the port but due to lack of interest.
If 486 support goes away, it won't be because suddenly the code has become unmaintainable after being fine for 25 years since the 486 was obsolete! It will because nobody has a machine to test or verify fixes on (although QEMU has improved this situation), or because the kernel or the x86 port decides to adopt a new feature which is more difficult to implement older CPUs (cmpxchg8b as another post mentioned).
So your post is totally misinformed and wrong. So with that out of the way here is the 386 removal changeset:
Net code change is fewer than 400 lines removed, much of it in boilerplate and config options changing.
"This tree removes ancient-386-CPUs support [which] plagued us with extra work whenever we wanted to change SMP primitives, for years."
There were no issues with spaghetti. They can and did maintain it just fine for many years. It was not removed to fix a bug, it was removed for lack of interest in doing the work to maintain it. And the extra work was not because of spaghetti it was because it required independent implementations of SMP primitives. As you see from the code change it was likely not the code itself that was the headache, but the testing of it.
> Technically Linux could once upon a time run on a 386
That's a really strange way to phrase it too. A 386 was the very first thing Linux was written to run on. There is no "technically" about it.
Ah I see, my instincts were wrong. Usually the complexity of the kernel is the root cause of problems. In this case, the rate of churn is the problem. Kernel devs want to change SMP primitives frequently, and having to go back and think about the 386 paradigm is a barrier to that goal. CPU manufacturers want to ensure that Linux uses their CPUs at maximum efficiency, so SMT primitive tweaking is a fact of life.
Since the days of 386 support, the kernel has only become much more modular and portable. It quite possibly supports more platforms and CPU architectures and families than any other OS ever written. Almost certainly true if you restrict it to a multitasking >= 32-bit OS with memory protection and virtual memory.
Many architectures and ports that have been removed or not merged were not due to being technically incapable of supporting the port but due to lack of interest.
If 486 support goes away, it won't be because suddenly the code has become unmaintainable after being fine for 25 years since the 486 was obsolete! It will because nobody has a machine to test or verify fixes on (although QEMU has improved this situation), or because the kernel or the x86 port decides to adopt a new feature which is more difficult to implement older CPUs (cmpxchg8b as another post mentioned).
So your post is totally misinformed and wrong. So with that out of the way here is the 386 removal changeset:
http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html
Net code change is fewer than 400 lines removed, much of it in boilerplate and config options changing.
"This tree removes ancient-386-CPUs support [which] plagued us with extra work whenever we wanted to change SMP primitives, for years."
There were no issues with spaghetti. They can and did maintain it just fine for many years. It was not removed to fix a bug, it was removed for lack of interest in doing the work to maintain it. And the extra work was not because of spaghetti it was because it required independent implementations of SMP primitives. As you see from the code change it was likely not the code itself that was the headache, but the testing of it.
> Technically Linux could once upon a time run on a 386
That's a really strange way to phrase it too. A 386 was the very first thing Linux was written to run on. There is no "technically" about it.