Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: Patch for 2.2.10 (Quelle surprise!) | Date | Fri, 9 Jul 1999 22:56:13 -0400 (EDT) |
| |
Jes Sorensen writes: > "Albert" == Albert D Cahalan <acahalan@cs.uml.edu> writes: >> Jes Sorensen writes:
>>> Looking at the example put forward so far, it is quite obvious that >>> the person suggesting it has not even looked at what other >>> architectures put in /proc/cpuinfo. >> >> If an architecture doesn't report a cross-platform feature, >> there is a bug. I would expect to find out: >> >> Is there any floating point hardware? How many processors are >> there? What is the BogoMIPS value? > > What memory management unit is in the box ... oops that one does not > exist on the x86.
You are very wrong about this. First of all, everything I listed is a generic cross-platform CPU feature. Second of all, you can report the MMU type as "i386mmu" or "integrated".
>> These should also be provided if possible: >> >> What is the clock speed? (rough estimate) (min, max, & >> current?) What company designed or produced the CPU? What is >> the CPU name? ("Pentium MMX") What is the version number? >> (5.4.3 for the Pentium MMX above) > > Whats the memory bus speed, whats the cache speed, whats the cache > size (L1/L2/L3) etc etc, how much junk do you want down there.
Your point? If the memory bus speed can be determined, report it. These are all cross-platform concepts.
>> Even the architecture-specific values should be in a common >> format. I ought to be able to write a nice GUI tool that >> displays a table of all the features, bugs, and interesting >> numbers. That would use a nice proportional font of course, so >> there would need to be a cross-platform way to tell labels >> apart from values. (else how can you align the columns right?) > > So you are saying that people should rewrite all existing tools so it > can be made easy for you to write a useless bells'n'whistles tool to > display things? No thank you very much.
That's a straw man. You can keep your crummy old backwards-compatible /proc/cpuinfo format. I intend to keep mine.
And why shouldn't I be able to put bells'n'whistles in userspace?
>> Let's say I wrote software that would use MMX on ia32, AltiVec >> instructions on PowerPC, and VIS on the SPARC. I want to test >> for the appropriate feature at runtime. How? Must I write >> several parsers? I would want to collect my data with one >> cross-platform parser. Then I could just query for a "VIS" >> boolean. > > Oh how, you mean that all CPUs that provide something "VIS"-like > should report it as VIS? If you want to program something architecture > specific like VIS or MMX, then you already have to know how to deal > with it.
**GROAN**
Hell no. I think you tried to misinterpret that, but...
Existing way:
I must write architecture-specific code to parse /proc/cpuinfo, along with code to actually use AltiVec, MMX, 3dNow, etc.
Better way:
I write generic code to query for features. This could be a parser. I write architecture-specific code to actually use the features, but this code can use the generic code to ask about features.
Vaguely like this:
#ifdef __i386__ if(cpu_feature_query(CF_3dNow) fn = render_3dnow; else if(cpu_feature_query(CF_KNI) fn = render_katmai; #endif #ifdef __JES_CPU__ if(cpu_feature_query(CF_UltraFoo3D) fn = render_ufoo3; else if(cpu_feature_query(CF_Foo3Dplus) fn = render_foo3p; else if(cpu_feature_query(CF_Foo3D) fn = render_foo3; #endif
Today, I can not write a generic cpu_feature_query() function. I have to write a parser for each architecture. That sucks.
Perhaps even worse is the ill-defined format. Try to guess the syntax of a /proc/cpuinfo file. Now, how do you know you are right? You are obviously _wrong_, because you guessed at something that is not defined. Kernel hackers often feel free to play with the layout.
- 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/
| |