Re: kern/44620: /proc/stat broken after acpi changes (?) and only shows one CPU in amd64-current

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

The following reply was made to PR kern/44620; it has been noted by GNATS.

From: yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)
To: njoly%pasteur.fr@localhost
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, htodd%twofifty.com@localhost
Subject: Re: kern/44620: /proc/stat broken after acpi changes (?) and only
 shows one CPU in amd64-current
Date: Thu, 24 Feb 2011 00:30:35 +0000 (UTC)

 > On Wed, Feb 23, 2011 at 07:03:41AM +0000, YAMAMOTO Takashi wrote:
 >> hi,
 >> 
 >> >  The `/proc/stat' code depends on MULTIPROCESSOR define/option which is
 >> >  not set when standalone module is build.
 >> >  
 >> >  While it's easy to fix for both i386 and amd64 where MULTIPROCESSOR is
 >> >  mandatory for quite some time, i'm not sure how to properly handle it
 >> >  for other archs ...
 >> 
 >> there's no point to have the MULTIPROCESSOR check in procfs these days.
 >> CPU_INFO_FOREACH should just work for the !MULTIPROCESSOR case.
 >> 
 >> there are archs which has optimized-version of CPU_INFO_FOREACH for
 >> !MULTIPROCESSOR, tho.  IMO it isn't worth to have this kind of micro
 >> optimizations.  performance critical code should not iterate cpus anyway.
 > 
 > Right, CPU_INFO_FOREACH should mostly work in both cases ... But some
 > archs have different curcpu definition depending on MULTIPROCESSOR.
 
 probably have a kernel-option-independent version of
 CPU_INFO_FOREACH/curcpu/curlwp/etc in the core kernel so that
 modules can just use it?
 
 YAMAMOTO Takashi
 
 > 
 > -- 
 > Nicolas Joly
 > 
 > Biological Software and Databanks.
 > Institut Pasteur, Paris.