Re: Cyrix 6x86MX and Centaur C6 CPUs in 2.1.102

James Mastros (
Thu, 21 May 1998 23:41:18 -0400 (EDT)

On Fri, 22 May 1998, [ISO-8859-1] André Derrick Balsa wrote:
> So personally, I don't care what goes into /proc/cpuinfo, I don't care
> if I get Bogomips ratings instead of MHz, I don't care if I get an
> entire list of Intel-only bugs,
On these, the basic issue is information overload vs. information underload
(not getting all of the information that you want). Myself, I'd take
overload over underload any day. I think that this has been the Linux
Philophisy from the day that printk was first implemented. (A bit after the
ababababababa... days, no dought.) However, we've tried to find a happy
medium. In this case, for statics only avaible from the kernel (this leaves
out MHz, BTW, which there has been a stable and accurate program around to
test for for about a year. Mail me privatly if you want a copy.) should be
avaible from /proc/cpuinfo, but not printed at bootup unless it is probable
that you would need to know them on a system that crashed/hung before
getting to where you can 'cat /proc/cpuinfo'. IMHO, of cource.

> and I don't even care if I get wrong CPU stepping information on non-Intel
> CPUs.
Now this is a matter of _wrong_ information -- write a patch, test it, and
make it ellagant (or at least not ugly). Then send it to Linus and

> However, I always feel a resistance to change. An example: 7 or 8 months
> ago, I posted both my observation of a kernel oops and a patch that
> worked around it.
Worked around it, or fixed it? Work-arounds are unlikly to make it into the
kernel, for idealistic reasons. Somtimes, we kernel-hackers (I use the first
person even though I hardly qualify as a kernel-hacker -- it makes me feel
better) care more about the quality of the code then it's ablity to
acatually _work_.

Indeed, if you have a problem with a workaoround but without a solution,
then it may be generaly best to point people in the right direction, rather
then simply posting a workaround. People are more liklely to work on fixing
it that way. Sad, but true.

> Now, the problem is that you guys think that most people understand
> what's going on. Well, the truth is they don't.
> When the average Linux user sees a Bogomips line in /proc/cpuinfo, he
> doesn't understand what this thing means. If it said MHz, OK.
The thing is that it isn't MHz, it's BogoMIPS. They aren't the same thing.
Again, I thing the Goodness of having that information easly avaible for
those who request it offsets the Badness of confusing people who look in the
deep dark depths (cating the files in /proc qualifies) without being
prepared to find stuff they don't understand. OTOH, the Badness of
thrusting this knowledge upon an unwitting public is more debatable (and
thus more debated.)

> Same goes for all the bug related lines, some of which are so old that
> they only apply to 386 CPUs (and people who are still using 386s don't
> parse /proc/cpuinfo, believe me).
I don't think the knowledge of a Linux user can be mesured by the power of
their systems. It wouldn't surprise me if Uberhackers commonly run 386es --
they are cheap, so you can have a lot of them, for routers and reduntant
machines and such.

> I believe in making Linux simpler to use and more user-friendly. I also
> think that assuming blindly that every x86 CPU is made by Intel, and
> that whatever differs from Intel must automatically be called a "bug",
> without even looking into it, is a shortsighted and biased attitude.
OTOH, Intel is the body that defines the ia32 standards. That's why the
name is "Intel Architecture 32", not "Intel et al Architecture 32". If a
processor's behivor deviates from that which the Intel specs specify, it is
buggy, whether it is Intel or Cyrix or AMD or TI or Transmeta. Then again,
if it deviates from the Intel chips on an undefined matter, or goes above
and beyond the call of duty, then the chip is better then the Intel
"equivlent" in that respect, and we should take advantage of those features
as best as we can.

-=- James Mastros

True mastery is knowing enough to bullshit the rest.
	-=- Me

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to