Messages in this thread | | | Date | Tue, 15 Apr 1997 11:30:28 -0700 (PDT) | From | Dan Hollis <> | Subject | Re: procfs problems |
| |
On Tue, 15 Apr 1997, Miguel de Icaza wrote: > > > And then, if people want to parse any of the extra information, they > > > should know the architecture specific information on the CPU before > > > attempting to parse it. > > It should be standardized. Right now there's *no* standardization in the > > kernel, which makes parsing the information the biggest pain in the ass. > > Having to write 5 different parsers for the same information is *not* the > > way to go. > Well, first problem is: which applications would really care about the > information on /proc/cpuinfo? i doubt there are any applications that > require this information besides probably the cpu type.
This should not be an excuse to be sloppy.
> We could have a standard part /proc/cpuinfo part for those > applications that care about this and a architecture-specific part.
User continues to scratch head and can't figure out why different architectures display the same type of information in completely different formats...
> The standard part should have: > > global: the port name, architecture type, number of cpus on the > system, number of active cpus on the system. > > per cpu: the cpu type, the fpu type, mmu type, bogomips. > > The rest should be architecture dependant.
And why pray tell does one huge /proc/cpuinfo entry make more sense than e.g /proc/cpu/0 /proc/cpu/1 /proc/cpu/2?
The SCSI system does it this way for multiple adaptors, IMHO it's The Right Way. Stuffing all the multiple CPU info in a single entry is the M$-way.
-Dan
| |