Re: [git pull] x86 updates for v2.6.28, phase #2 - PAT updates

[Linus Torvalds]

On Fri, 10 Oct 2008, Ingo Molnar wrote:
> 
> Ingo Molnar (12):
>       Revert "reduce tlb/cache flush times of agpgart memory allocation"
>       Revert "introduce two APIs for page attribute"
>       Revert "x86: handle error returns in set_memory_*()"
>       Revert "x86: track memtype for RAM in page struct"
>       Revert "x86, cpa: global flush tlb after splitting large page and before doing cpa"
>       Revert "x86, cpa: remove cpa pool code"
>       Revert "x86, cpa: fix taking the pgd_lock with interrupts off"
>       Revert "x86, cpa: dont use large pages for kernel identity mapping with DEBUG_PAGEALLOC"
>       Revert "x86, cpa: make the kernel physical mapping initialization a two pass sequence"
>       Revert "x86, cpa: remove USER permission from the very early identity mapping attribute"
>       Revert "x86, cpa: rename PTE attribute macros for kernel direct mapping in early boot"
>       x86, pat: cleanups

So half of the commits by Suresh were reverted. 

Not only that, they were reverted WITH ABSOLUTELY NO EXPLANATIONS OF WHY 
THEY WERE CLEARLY BUGGY PILES OF CRUD. The revert messages are just things 
like

	This reverts commit <sha1>.

which makes both the original commit _and_ the revert just totally 
pointless, because we didn't learn anything.

So tell me exactly why I should pull this series again? Why should I ever 
pull _any_ tree that cannot explain its commits? 

Next time you revert, explain _why_. And if a tree has this many reverts 
(and by "this many" I mean "dammit, there are three times as many commits 
as there should be, because a third of the commits are crap, a third of 
the commits are reverts of that crap, and a third of the commits actually 
remain"), why should I pull it again? 

In other words, why shouldn't I just think that this whole branch is a 
total failure, which is what I think right now?

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/