Re: port-i386/38634: x86 kernels no longer produces information about cpus

[Andrew Doran <ad%netbsd.org@localhost>]

The following reply was made to PR port-i386/38634; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-i386/38634: x86 kernels no longer produces information about 
cpus
Date: Mon, 12 May 2008 13:39:51 +0100

 On Mon, May 12, 2008 at 11:20:01AM +0000, chris%NetBSD.org@localhost wrote:
 
 > dmesg used to contain information about cache sizes and feature flags for 
 > cpus (even if it was wrong for non-cpu0s).
 > 
 > This information has been completely stripped and appears to have moved to 
 > userland.
 > 
 > This will cause issues should cpuctl and the kernel have different code.  As 
 > a bug in the kernel code may not be present in cpuctl and a cache or tlb 
 > maybe detected incorrectly.
 
 Please excuse me for being forthright, but I get the sense that this is a
 sentimental reaction to change. The majority of the information gathered and
 printed by the kernel was of no use at runtime and was only for eye candy
 purposes.
 
 Items like the TLB and L1 cache information are never used. The list of
 feature flags reported was incomplete and even at that, it was already a
 large amount of information to casually sift through.
 
 The CPU names were well out of date and in any case, only described what was
 printed on the box that the CPU came in: it's marketing text and says
 nothing about the architecture. Have a P-III Xeon? It could be a rebranded
 P-II with more cache bolted on, or if you are lucky it's actually based on a
 P-III core. The list goes on. Only the ID will tell you for sure what it is,
 and that's why we still print it.
 
 > To confirm the CPU caches and other information now requires you can get to 
 > userland, which may not be possible on all systems (eg a test boot on a new 
 > processor, or other installation issues)
 
 That information is of little use when it comes to diagnosing boot failures.
 It's certainly interesting for reasons of verification and benchmarking. I
 agree that there is a need to print it, but it's not a job for the kernel.
  
 > It also doesn't allow verification of changes to the kernel's detection of 
 > the CPU features without adding the printf's back in.
 
 Well, I found and fixed quite a few bugs when overhauling it and that was
 through tedious reading of the code and verification of changes. The
 printout didn't help me with that.
 
 Andrew