Re: x86 status was Re: -mm merge plans for 2.6.23

[Linus Torvalds <torvalds@linux-foundation.org>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/