[New Proposal] cpuinfo, but not directly via /proc
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
Reply to: