On Thu, 12 Jul 2007, Thomas Gleixner wrote:
>
> The HPET change, which is the larger part of the conversion set simply
> because we now share the code with i386, might be split out by disabling
> HPET in the first step, doing the PIT / APIC conversion and then the
> HPET one in a separate step.
But that misses the point. It means that the commit that actually
*changes* the code never actually gets tested on its own
Why not just fix up the HPET code so that it can be shared *first*.
Without the other conversion? Really - What's so wrong with the hpet.c
changes in the *absense* of conversion to clockevents? Those changes seem
to be totally independent - just abstracting ou tthe
"hpet_get_virt_address()" stuff etc.
None of that has anything to do with clockevents, as far as I can see.
In other words, you now change a i386-only file, and maybe it breaks
subtly on i386 as a result. Wouldn't it be nicer to see that breakage as a
separate event?
Then, the x86-64 clockevents code will switch over entirely, but now it
switches over to something we can say has gotten testing, and we know the
switch-over won't break any 32-bit code, because the switch-over literally
didn't change anything at all for that case.
See? THAT is what I mean by "gradual". Bugs happen, but if we can make
_independent_ bugs show up in _independent_ commits, that will make it
much easier to figure out what happened.
The same is true of a lot of the APIC timer code. Sure, that patch has the
actual conversion in it, and you don't have the cross-architecture issues,
but more than 50% of the patch seems to be just cleanup that is
independent of the actual switch-over, no?
Again, if it was done as a "one patch for cleanup, and another patch that
actually switches the higher-level interfaces around", then the two mostly
independent issues (of "hardware access/initialization" vs "higher-level
changes in how it got called") get done as two independent commits.
And no, I really probably wouldn't ask for this, but 2.6.21 showed
*exactly* this problem. Trivial debugging helps like "git bisect" didn't
help at all, because all the problems started when the new code was
"activated", not when it was actually brought in.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
