Re: procfs problems

Dan Hollis (
Tue, 15 Apr 1997 11:30:28 -0700 (PDT)

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

> 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