lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject/proc/cpuinfo consistency
On Sun, 20 Sep 1998, Brandon S. Allbery KF8NH wrote:

> I did, in fact it was another reason that I posted the above. Consistent
> interfaces as suggested are well, fine, and good, but (XthreadX with UDI)
> you can't always maintain interface consistency when that interface is
> broken, as with the dev->flush() changes. And /proc/cpuinfo strikes me as
> an interface which may well have problems being simultaneously consistent
> and complete while addressing multiple CPU architecture families (heck, it's
> been a problem just between Intel, AMD, and Cyrix; should we be surprised at
> problems between x86 and PPC, Alpha, SPARC, ...?).

I *wouldn't* mind the difference so much if they'd made it use all lower
case letters *and* a space before the ':' and a space after that. Then I
would have no problems parsing the /proc/cpuinfo file at all.

i.e, on Amiga-Linux they have this horrible thing:
CPU: 68040
BogoMips: 16.58

whilst on Intel it's as:
cpu family : 6
model : 5
model_name : Pentium II
bogomips : 400.59

At least the Alpha /proc/cpuinfo is consistent with Intel, and the
PowerPC /proc/cpuinfo is consistent as well.

I suggest that someone should patch Linux m68k's /proc/cpuinfo for
consistency. I believe that should be as:

cpu : 68040
bogomips : 16.58

Then, it is trival to parse.

At the moment my program has a lot of #ifdefs to compile code for each
type of architecture that Linux runs on. I'd *love* to get rid of that and
have a nice generic function for parsing /proc/cpuinfo for *any* version
of Linux 2.1.x.

The uname() function works beautifully on all architectures and has no
#ifdefs. Why can't we have something like that for the cpuinfo stuff?

Maybe I'll devise an shared library (cpuinfo.so) which would have
cpuinfo() as a function that all programs could call to obtain the
hardware information. This IMHO would enhance independence of these
programs as they wouldn't have to worry about /proc/cpuinfo differences.
Comments anyone?

My current code is set up to return a struct for hardware information,
much like what uname() does, so it is quite portable, and I can easily
turn that into a library.

Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.122 #43 Sat Sep 19 10:54:36 EDT 1998 One AMD 486 DX/4 processor, 49.77 total bogomips, 32M RAM


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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