[New Proposal] cpuinfo, but not directly via /proc

Ralf Flaxa rf at caldera.de
Fri Jan 4 04:30:51 PST 2002


Disclaimer:
[ Inappropriate bashing by Christoph against the glibc folks removed.   ]
[ This is *NOT* Caldera's position and we very much appreciate all the  ]
[ hard work people put into glibc. Caldera believes instead that Linux  ]
[ needs certain standards in order to maintain and improve its success  ]
[ in the business and enterprise world. That's why we support e.g. LSB. ]

We would like to make a new proposal - see below.

On Fri, Jan 04, 2002 at 12:28:37AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 03, 2002 at 05:53:38PM -0500, Stuart Anderson wrote:
> 
> > I'd like avoid /proc completely, but we needed a way to determine what
> > processor features are available (especially on IA32). Without this, we have
> > to choose the i486 feature set as the least common denominator (ie no MMX, etc).
> 
> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?
> 
> This way applications do not have to worry about changes to kernel
> internals.

I like this idea, be it implemented via "uname" or some other interface.

Reading this thread and previous requests I see a need by ISVs and
applications to determine at runtime certain processor related features.

They can roughly be grouped into:

1. number-crunching power in general

	o number of CPUs
	o CPU family and type
	o BogoMips (per CPU and/or overall)
	o SMP capabilities (here kernel scalability could be an item)

2. features specific to a processor

	o for x86 e.g. the "flags" and *_bug fields
	o info about FPU, MMU and the like

I have asked Christoph to work on a proposal and present it
to this list. I think we agree that there is a need and demand
for a standard way to gather this info and that /proc/cpuinfo
was just a bad start - so I would like to give it another chance.

This is Ralf speaking as director of Linux development at Caldera
and as technical lead for the LSB sample implementation.

	Ralf





More information about the lsb-discuss mailing list