lkml.org 
[lkml]   [1999]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Patch for 2.2.10 (Quelle surprise!)
Date
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/

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