[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

[ 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.


Reply to: