All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jaswinder Singh Rajput <jaswinder@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
Date: Wed, 10 Jun 2009 10:14:09 -0700	[thread overview]
Message-ID: <4A2FE9E1.3020705@zytor.com> (raw)
In-Reply-To: <1244652044.3295.10.camel@ht.satnam>

>>>>
>>> The more I'm thinking about this I think it was a mistake to put cpuid
>>> level: there in the first place, too.  My opinion is increasingly to
>>> leave this to x86info or other user-space tools.
>>>
>> cpuid level is as important as cpu family, model and stepping.
>>
>> For Intel, in some cases cpuid level is more important then cpu family,
>> model and stepping. Like you cannot tell by looking at cpu family, model
>> and stepping which model is new and which is old like 05_01 or 06_1A or
>> 0F_03H ?
>>
>> But by looking at cpuid level and extended cpuid level you can tell
>> which is new and which is old and which supports more features.
>>
>> So cpuid level and extended cpuid level is better scale than cpu family,
>> model and stepping. So I think hiding this valuable information is a
>> crime.
> 
> cpuid level and extended cpuid level tells the information about Intel
> processor model.  Do you still think it is useless and should not be present
> in /proc/cpuinfo .
> 

I think it's pointless, because if you're doing this kind of stuff you
might as well talk to CPUID directly.  We have a CPUID interface
already.  The kernel isn't meant to replicate x86info or any of those
tools -- it really can't, and at that point why stop at x86info... we
could replicate arbitrary applications at that point.

As far as extended CPUID, why only the 0x0000 and 0x8000 ranges?
Transmeta used 0x8086 and VIA uses 0xC000, but we don't even cache those
internally, nevermind display them.

I'm not really all that doctrinal about this, but I'd like to get a
decent answer to the question "where does it stop, *and why*".  It's a
slippery slope, and without a target, it goes on forever.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2009-06-10 17:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12  7:14 [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo Jaswinder Singh Rajput
2009-05-12 13:39 ` Borislav Petkov
2009-05-12 13:49   ` Jaswinder Singh Rajput
2009-05-12 14:10     ` Borislav Petkov
2009-05-12 16:40       ` H. Peter Anvin
2009-05-12 18:13         ` Borislav Petkov
2009-05-12 18:47           ` H. Peter Anvin
2009-05-12 19:49             ` Borislav Petkov
2009-06-05 19:20         ` Jaswinder Singh Rajput
2009-05-13  6:21 ` Andrew Morton
2009-05-13  8:03   ` Andi Kleen
2009-06-05 18:38   ` Jaswinder Singh Rajput
2009-06-05 20:55     ` H. Peter Anvin
2009-06-06  4:23       ` Jaswinder Singh Rajput
2009-06-10 16:40         ` Jaswinder Singh Rajput
2009-06-10 17:14           ` H. Peter Anvin [this message]
2009-06-10 17:42             ` Borislav Petkov
2009-06-10 17:48               ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A2FE9E1.3020705@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=jaswinder@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.