lkml.org 
[lkml]   [1997]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.215 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site