From: Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>
To: Nathan Lynch <nathanl@austin.ibm.com>
Cc: Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] unexport register_cpu and unregister_cpu
Date: Wed, 26 Jan 2005 11:26:19 -0800 [thread overview]
Message-ID: <20050126112619.A27536@unix-os.sc.intel.com> (raw)
In-Reply-To: <1106766630.13753.23.camel@biclops>; from nathanl@austin.ibm.com on Wed, Jan 26, 2005 at 01:10:30PM -0600
On Wed, Jan 26, 2005 at 01:10:30PM -0600, Nathan Lynch wrote:
> On Wed, 2005-01-26 at 10:22 -0800, Keshavamurthy Anil S wrote:
> > On Wed, Jan 26, 2005 at 12:55:47AM -0600, Nathan Lynch wrote:
> > > http://linus.bkbits.net:8080/linux-2.5/cset@4180a2b7mi2fzuNQDBOQY7eMAkns8g?nav=index.html|src/|src/drivers|src/drivers/base|related/drivers/base/cpu.c
> > >
> > > This changeset introduced exports for register_cpu and unregister_cpu
> > > right after 2.6.10. As far as I can tell these are not called from any
> > > code which can be built as a module, and I can't think of a good reason
> > > why any out of tree code would use them. Unless I've missed something,
> > > can we remove them before 2.6.11?
> >
> > No this is not correct. ACPI processor.ko driver which supports
> > physical CPU hotplug needs register_cpu() and unregister_cpu() functions
> > for dynamically hotadd/hotremove support of the processors.
>
> I do not understand your objection. The processor module does not call
> the interfaces in question directly. They are called only from arch
> setup code (e.g. arch/ia64/kernel/topology.c) which is never built as a
> module.
Oops.. Sorry, its my fault.
>
> > Please see drivers/acpi/processor_core.c
> > acpi_processor_hotadd_init() -> arch_register_cpu() ->
> > ->register_cpu().
>
> Sure -- the arch_register_cpu and arch_unregister_cpu symbols need to be
> exported for this use (and they are). Exporting register_cpu and
> unregister_cpu is unnecessary.
I agree with you 100%.
>
> I double-checked an ia64 build with CONFIG_ACPI_HOTPLUG_CPU=y and
> CONFIG_ACPI_PROCESSOR=m and saw no errors or warnings caused by the
> change...
Andrew, I have no objection with Nathan's patch.
thanks,
Anil
prev parent reply other threads:[~2005-01-26 23:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-26 6:55 Nathan Lynch
2005-01-26 18:22 ` Keshavamurthy Anil S
2005-01-26 19:10 ` Nathan Lynch
2005-01-26 19:26 ` Keshavamurthy Anil S [this message]
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=20050126112619.A27536@unix-os.sc.intel.com \
--to=anil.s.keshavamurthy@intel.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathanl@austin.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome