Rene Herman wrote:
quoted text
> On 07-05-08 22:52, Thomas Gleixner wrote:
> 
>>> And why do we need this clear_cpu_cap(c, X86_FEATURE_PAT) and then 
>>> manual setting of X86_FEATURE_PAT at all?
>>
>> The reason is to make cpu_has_pat a useful check and to avoid checking
>> cpu vendors, families and models inside of the PAT code. That's a good
>> thing actually, because the PAT code only cares about that cpu_has_pat
>> flag.
>>
>> Clearing it in the cpuinfo is just a cosmetic side effect which does
>> no harm at all.
> 
> Oh yes, it does. It makes people unaware that their CPUs _should_ be
> supporting PAT. The thing's not called /proc/kernelinfo for a reason.
> 

Okay, that is utter nonsense.  /proc/cpuinfo has always been, and will 
always be, the CPU *AS THE KERNEL SEES IT*.  If you want something else, 
use x86info(1).

quoted text
> And would yelling at people how shuffle in code without (publicly at
> least) addressing one of your fellow arch maintainers objections and
> Pavel's review comments about code duplication without a single line
> of explanation/changelog do?

We did discuss this (over IRC, I'm afraid), and came to the conclusion 
that it's too risky to do the proper thing (blacklist) straight out the 
gate.  Consider it a staged implementation.  The reason for this is that 
some of the earlier chips have downright frightening errata w.r.t. PAT. 
  *At this point*, we'd have no reasonable way to filter those bug 
reports from the issues with the software itself.

So, one step at a time.  PAT is massively overdue in Linux, so it's no 
wonder you're anxious about it, but we need a modicum of caution here.

	-hpa
--
unsubscribe notice
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/