[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-i386/38634: x86 kernels no longer produces information about cpus
The following reply was made to PR port-i386/38634; it has been noted by GNATS.
From: Chris Gilbert <chris%dokein.co.uk@localhost>
Subject: Re: port-i386/38634: x86 kernels no longer produces information about
Date: Mon, 12 May 2008 19:47:34 +0100
Andrew Doran wrote:
> The following reply was made to PR port-i386/38634; it has been noted by
> From: Andrew Doran <ad%netbsd.org@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> 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
Perhaps so, I just prefer to at least have a vague idea if NetBSD gets
the chip or not.
> 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.
So why do we even bother working it out then? I thought we did use some
of the cache info to determine page colouring.
Perhaps if we just displayed the stuff we do need and use, it would
allow tweaks/updates to be checked, particularly when asked to check
someone elses change works on your hardware.
> > 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.
If the printouts didn't help then should they have been expanded to help?
Main Index |
Thread Index |