All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Borislav Petkov <bp@alien8.de>,
	Kyung Min Park <kyung.min.park@intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, gregkh@linuxfoundation.org,
	ak@linux.intel.com, tony.luck@intel.com,
	ravi.v.shankar@intel.com, ricardo.neri@intel.com
Subject: Re: [RFC PATCH 0/3] Add Documentation for /proc/cpuinfo flags
Date: Thu, 11 Jun 2020 07:05:08 -0700	[thread overview]
Message-ID: <5b6cc9c0-491f-689f-b7e9-e2c7a32182aa@intel.com> (raw)
In-Reply-To: <20200610203537.GT14118@zn.tnic>

On 6/10/20 1:35 PM, Borislav Petkov wrote:
> On Wed, Jun 10, 2020 at 01:06:58PM -0700, Kyung Min Park wrote:
>> Include two instances of features for which there are not implemented
>> use cases in the kernel.
>>
>> Patch 1 creates a new documentation for /proc/cpuinfo flags bits.
>> Patch 2 adds X86_FEATURE_SERIALIZE.
>> Patch 3 adds X86_FEATURE_TSXLDTRK.
>>
>> This RFC series has been reviewed by Dave Hansen.
> Yeah, and he and I talked about this on IRC. If you really want to dump
> CPUID to see what's there, we should do a userspace tool in tools/ or
> even use the ones which are already out there: x86info, cpuid, ...
> 
> Just adding X86_FEATURE_* flags without usage in the kernel makes no
> sense and will cause unnecessary bloat and doesn't help one bit because
> userspace simply calls CPUID directly.

Could we ignore the new flag patches for the moment and make sure
everyone is on board with what the new Documentation/ says?

  reply	other threads:[~2020-06-11 14:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 20:06 [RFC PATCH 0/3] Add Documentation for /proc/cpuinfo flags Kyung Min Park
2020-06-10 20:06 ` [RFC PATCH 1/3] Documentation/x86: Add documentation for /proc/cpuinfo feature flags Kyung Min Park
2020-06-15 18:15   ` Borislav Petkov
2020-06-15 18:31     ` Luck, Tony
2020-06-15 18:37       ` Dave Hansen
2020-06-15 18:40       ` gregkh
2020-06-15 23:44     ` Kyung Min Park
2020-06-10 20:07 ` [RFC PATCH 2/3] x86/cpufeatures: Add enumeration for SERIALIZE instruction Kyung Min Park
2020-06-10 20:07 ` [RFC PATCH 3/3] x86/cpufeatures: Enumerate TSX suspend load address tracking instructions Kyung Min Park
2020-06-10 20:35 ` [RFC PATCH 0/3] Add Documentation for /proc/cpuinfo flags Borislav Petkov
2020-06-11 14:05   ` Dave Hansen [this message]
2020-06-11  5:34 ` Greg KH

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=5b6cc9c0-491f-689f-b7e9-e2c7a32182aa@intel.com \
    --to=dave.hansen@intel.com \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=kyung.min.park@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=ricardo.neri@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --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.