* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 10 Jun 2009, Ingo Molnar wrote: > > > > > * Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > This code has been NAK-ed by the x86 maintainers: > > > > > > > > - Due to the absurd irrelevance of Voyager/x86/Linux hardware > > > > > > > > - Due to the thousands of lines of of code it adds to arch/x86 > > > > to support a 486/P5 era piece of hardware > > > > > > > > - and due to its negative track record of: > > > > > > > > v2.6.27.0: Voyager was broken - it did not even build. (!) > > > > v2.6.28.0: Voyager was broken - it did not even build. (!) > > > > v2.6.29-rc5: Voyager was broken - it did not even build. (!) > > > > > > So Ingo you are arguing "It didn't work in some releases so we > > > want to make it continue not to work by trying to keep the fixes > > > out" ? > > > > No. This code is not in Linux right now, and that i see no reason to > > put it back, for the (many) reasons outlined. > > Ingo, "absurd irrelevance" is not a reason. If it was, we'd lose > about half our filesystems etc. > > Neither is "thousands of lines of code", or "it hasn't always > worked". Again, if it was, then we'd have to get rid of just about > all drivers out there. > > So give some real reasons. "It's a maintenance nightmare because > it does xyz" might be a reason. But then we really need to see the > "xyz" part too. > > Alan is definitely right that we're likely to see more of the > "non-PC" platforms as x86 tries to do embedded. That is true, and the whole painful conversion from the build-time 32-bit sub-arch code to the unified runtime quirk code (which is really 'non-PC platform driver' kind of thing) that i did a few months ago was partly about that. I dont dispute that aspect - in fact we merged a rare subarch as well. But Voyager has been the most painful subarchitecture by far - for an extended period of time the code didnt even build in its defconfig - and it is also the most useless one as well. So it was just a token really. The only action i got from James was when _I_ implemented the proper, runtime subarch mechanism and when we actually _removed_ the voyager code. Before it James resisted such changes, see this thread almost a year ago, in the Nth "voyager breaks the build" discussion, where i suggested: " btw., any chance to turn it into a quirk space thing? " http://lkml.org/lkml/2008/4/21/441 I got no action from James for my technical requests. Right now i dont see any guarantee that this wont be repeated, once the code is upstream again after meeting some threshold minimally. Voyager was a painful experience to all x86 maintainers and i'd expect pushers and supporters of rarely used code to do such work, not maintainers. Are the quality thresholds i outlined in the previous thread(s) unreasonable? They were: " If the code is absolutely trouble-free out of tree, for an equivalent amount of time (3 kernel releases or so), and gathers users/testers/etc., then we might add it, after a thorough technical review. " http://lkml.org/lkml/2009/4/19/181 Given that there are only two known boxes left (both James's, the other one went missing in action somewhere in Brasil), the 'gather testers' bit is unreasonable i guess. 'Prove you can stay trouble free' is more realistic. Dunno. See for example what happened in linux-next today: Voyager broke x86 and didnt even build, and Stephen had to keep it out of today's linux-next build. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
