From: hpa@zytor.com
To: Borislav Petkov <bp@suse.de>
Cc: linux-tip-commits@vger.kernel.org,
tip-bot for Borislav Petkov <tipbot@zytor.com>,
mingo@kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de
Subject: Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
Date: Tue, 10 Jan 2017 08:40:39 -0800 [thread overview]
Message-ID: <691CAE2B-2FDC-44CA-8731-D70C91E94320@zytor.com> (raw)
In-Reply-To: <20170110090415.46htye4aczidzvh2@pd.tnic>
On January 10, 2017 1:04:15 AM PST, Borislav Petkov <bp@suse.de> wrote:
>On Mon, Jan 09, 2017 at 04:19:29PM -0800, hpa@zytor.com wrote:
>> Any reason to not make these interfaces (leaf, subleaf) from the
>start?
>
>Two, actually:
>
>1. I modelled them after the cpuid_<reg>(op) versions
You are introducing a new API; makes more sense to do it right from the start. The only reason not to have a subleaf for the non-native variants is that they may decay into a function call so there is an extra cost.
>2. I don't think we need the subleaf variant right now.
But at some point we will. Just consider leaf 7.
>But, when we do, we can do that when we cross that bridge and add
>
>native_cpuid_<reg>(leaf, subleaf)
>
>which gets called by the native_cpuid_<reg>(leaf) variants.
C doesn't allow function name overloading ;) (Well, except the C11 type hacks; to the best of my knowledge that doesn't in any way support argument *count* overloading.)
This means that the naming will be awkward at best.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2017-01-10 16:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-09 11:41 [PATCH 0/5] x86/microcode: More urgent fixes Borislav Petkov
2017-01-09 11:41 ` [PATCH 1/5] x86/CPU: Add native CPUID variants returning a single datum Borislav Petkov
2017-01-09 22:16 ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2017-01-10 0:19 ` hpa
2017-01-10 9:04 ` Borislav Petkov
2017-01-10 16:40 ` hpa [this message]
2017-01-10 17:09 ` Borislav Petkov
2017-01-09 11:41 ` [PATCH 2/5] x86/microcode: Use native CPUID to tickle out microcode revision Borislav Petkov
2017-01-09 22:16 ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2017-01-09 11:41 ` [PATCH 3/5] x86/microcode/intel: Add a helper which gives the " Borislav Petkov
2017-01-09 22:17 ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2017-01-09 11:41 ` [PATCH 4/5] x86/microcode/intel: Fix allocation size of struct ucode_patch Borislav Petkov
2017-01-09 11:41 ` [PATCH 5/5] x86/microcode/intel: Use correct buffer size for saving microcode data Borislav Petkov
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=691CAE2B-2FDC-44CA-8731-D70C91E94320@zytor.com \
--to=hpa@zytor.com \
--cc=bp@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=tipbot@zytor.com \
/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.