> > You may argue that, since the kernel has a workaround for this issue, > > this is a moot point. But if some developer has a better idea for the > > kernel heuristic, how can the new code be tested, if not on the real > > hardware? > > > > The problem with this story is that the purported reasons for supporting old > architectures is to shake out bugs. How do the bugs get shaken out? By > exercising shared, core functionality in distinctive ways. > > Idiosyncracies such as the above are not the type of thing that helps shake > out core bugs.
You've missed the point. These idiosyncracies must be stepped over, so that we can have working platforms different from x86, to then go discover the core bugs! Luckily we have people in our group who support such other architectures in our tree, to give us this capability. Let's face it. OpenBSD has this as a bug reducing mechanism available, and most other systems do not anymore, having decided to chase only the market-chosen architectures. It is a true many-eyes "machined" solution. What other community has users who commonly run upstream software on 64-bit big-endian strict alignment platform with register windows adjusting the frames in odd ways, or 32-bit big-endian ones with mutex alignment requirements, or a pile of other requirements. Quite frankly, I am not alone in being sick of people who don't use emulators, stepping in to tell we should use emulators. Finally, we have people who want to work on those architectures. You prefer they quit? You think their experience and the time they spend will be better spent somewhere else, that they will continue to be valuable additions in some other role? First you are wrong, and secondly, who gave you the moral authority to try to reassign their time? Why is there this effort to convince us to do less?
