tags 449307 - patch thanks On Sunday 09 December 2007 16:42:42 Mattia Dongili wrote: > On Wed, Dec 05, 2007 at 10:09:28AM +1000, Kel Modderman wrote: > > On Wednesday 05 December 2007 09:54:30 Mattia Dongili wrote: > > ... > > > > and guess how cpufreq-info reads the number of cores? :) > > > > From /proc/stat. > > haha, sorry... funny thing is that I wrote that code... I should have > known about it. > > ... > > On Wed, Dec 05, 2007 at 01:19:22PM +1000, Kel Modderman wrote: > > Hi, > > > > My previous argument was flawed. Here goes another try. > > > > Rather than parse /proc/cpuinfo, use the same information cpufreq-info > > has about the cpu's. It currently gets that information from /proc/stat, > > so it makes since not to parse different files to harvest the same > > information. > > > > print_cpus_index.patch adds an option to cpufreq-info to print the index > > of each cpu in system. This option can be used by a variety of scripts, > > including cpufrequtils.init, to enumerate a list of cpu indices to > > perform actions on. > > Sorry again, I don't want to be rude and appreciate your help but > actually a lot more interesting implementation would be to check within > the cpufreq subsystem in /sys which cores we really need to change by > inspecting the affected_cpus map.
Sounds better, yes. > This would be cpufreq specific knowledge that can fit into cpufrequtils, > other than that I can't really see the point of implementing this > generic cpu-index thing in cpufreq-info when this information is > available system-wide and parseable with very little effort. It just makes more sense to me to parse the same file/information that cpufrequtils does, rather than similar information exported in different format to a different location. Forget about the patch. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
