Comment Re:Pare down the bloat (Score 1) 54
I suspect that it depends on how strongly or weakly the 'bloat' is connected to other things; and what supporting them involves.
Something like not having TSC (which itself comes in several variants depending on whether it's from the era where you actually had 'a' CPU that just ran at a speed, or if it's one of the ones that tries to compensate for the complications of variable clocks and multiple cores) presumably comes up in a variety of nasty places related to the bad things that happen when things are not done in the expected order.
Just some random PCI device that nobody developing actually owns anymore is presumably at risk of unnoticed regressions; but (especially with the amount of PCI DNA that got carried over into PCIe or was used for the software-visible interface of some system on chip that skipped the cost of actually implementing a 32 bit parallel multidrop bus out to the PCB but either specifically sought compatibility or couldn't justify cooking up something custom when the peripherals they were integrating were all derivatives of PCI designs) it's not necessarily much maintenance overhead for it to just exist on a 'cool if it works for you' basis as a module that you probably don't need.
There's also the secondary matter of the fact that 'the kernel' has a limited number of people directly focused on its interests in the abstract; rather than some hardware vendor, distro, enthusiast, or hyperscaler's interests. If preserving hardware compatibility is directly contrary to the interests of supporting the major contemporary use case of fairly large 64 bit x86 servers and embedded ARM widgets (as 486 and pre-TSC 685-ish likely was) it's going to have relatively few friends among the people actually doing the work. If someone wants to maintain some weirdo HAM radio interface card that merely assumes the existence of PCI it's not clear anyone will go out of their way to help if they need to update something to cope with a change elsewhere; but it's not like the Ministry of Kernel is going to order them to go find bugs in the implementation of CXL memory because that's where the money is.
Something like not having TSC (which itself comes in several variants depending on whether it's from the era where you actually had 'a' CPU that just ran at a speed, or if it's one of the ones that tries to compensate for the complications of variable clocks and multiple cores) presumably comes up in a variety of nasty places related to the bad things that happen when things are not done in the expected order.
Just some random PCI device that nobody developing actually owns anymore is presumably at risk of unnoticed regressions; but (especially with the amount of PCI DNA that got carried over into PCIe or was used for the software-visible interface of some system on chip that skipped the cost of actually implementing a 32 bit parallel multidrop bus out to the PCB but either specifically sought compatibility or couldn't justify cooking up something custom when the peripherals they were integrating were all derivatives of PCI designs) it's not necessarily much maintenance overhead for it to just exist on a 'cool if it works for you' basis as a module that you probably don't need.
There's also the secondary matter of the fact that 'the kernel' has a limited number of people directly focused on its interests in the abstract; rather than some hardware vendor, distro, enthusiast, or hyperscaler's interests. If preserving hardware compatibility is directly contrary to the interests of supporting the major contemporary use case of fairly large 64 bit x86 servers and embedded ARM widgets (as 486 and pre-TSC 685-ish likely was) it's going to have relatively few friends among the people actually doing the work. If someone wants to maintain some weirdo HAM radio interface card that merely assumes the existence of PCI it's not clear anyone will go out of their way to help if they need to update something to cope with a change elsewhere; but it's not like the Ministry of Kernel is going to order them to go find bugs in the implementation of CXL memory because that's where the money is.