From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <bp@alien8.de>, Borislav Petkov <bp@amd64.org>,
X86-ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Borislav Petkov <borislav.petkov@amd.com>
Subject: Re: [RFC][PATCH 2/2] x86, cpu, amd: Add a per-vendor BSP function
Date: Mon, 08 Aug 2011 17:13:17 -0500 [thread overview]
Message-ID: <4E405F7D.9000701@zytor.com> (raw)
In-Reply-To: <20110808215713.GB22088@liondog.tnic>
On 08/08/2011 04:57 PM, Borislav Petkov wrote:
>>
>> This is totally going backwards. We *should* be using struct cpu_dev
>> rather than switch statements for this.
>
> Right, but all the cpu_dev things are annotated with __cpuinitconst
> because they're used in CONFIG_HOTPLUG_CPU. __init, OTOH, will be
> discarded once we're done booting. So, we can't convert cpu_dev
> to __initdata because we need it for cpu hotplug and we want the
> run_on_bsp() functionality to be __init since it runs once on boot.
>
> Maybe leave cpu_dev in __cpuinit let it have an __init member which is
> the ->run_on_bsp()? Does that even work?
>
I don't think so, which is a fundamental shortcoming of our way of
handling these kinds of pointers. One way to deal with it would be to
make struct cpu_dev __initconst and copy it into a __cpuinit variable at
init time.
Either way, I'd rather leave the routines in cpuinit memory than adding
another multiplex.
-hpa
next prev parent reply other threads:[~2011-08-08 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 18:57 [RFC][PATCH 0/2] x86, CPU: Run stuff on the BSP Borislav Petkov
2011-08-08 18:57 ` [RFC][PATCH 1/2] x86, CPU: Drop second get_cpu_cap prototype Borislav Petkov
2011-08-08 18:57 ` [RFC][PATCH 2/2] x86, cpu, amd: Add a per-vendor BSP function Borislav Petkov
2011-08-08 20:56 ` H. Peter Anvin
2011-08-08 21:57 ` Borislav Petkov
2011-08-08 22:13 ` H. Peter Anvin [this message]
2011-08-09 13:05 ` 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=4E405F7D.9000701@zytor.com \
--to=hpa@zytor.com \
--cc=borislav.petkov@amd.com \
--cc=bp@alien8.de \
--cc=bp@amd64.org \
--cc=linux-kernel@vger.kernel.org \
--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.