Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: >> I was wondering if we want to first add the "reasonable fallback" >> Eric mentioned ealier, and then build on top, whose result may look >> like the attached. > > I'm fine with a well-focused patch which just fixes the reported > problem; the "reasonable fallback" change can be layered atop at any > time. Yeah, I never suggested to do these in a single patch. Since I would think that it is easier to do and review a patch that cleans up the code and adds a reasonable fallback before adding new support for sparc or alpha (after all, such a clean-up is also for longer term maintainability---by definition, it must be easier to add new support to the result of a clean-up than the original, or it is not a clean-up), I suggested to first add such a change. What you saw was how the result of "then build on top" would have looked like. > I had a more all-inclusive change in mind. These number-of-cpu checks > are in order from least to most costly but they are not necessarily > mutually exclusive. As such, my thinking was that the logic would fall > through to the next check if the preceding check produced zero or > nonsense. OK. All the more reason to clean-up first, then? If we pile more on top of the current structure, it would make the later clean-up more cumbersome, wouldn't it? Thanks.
