>This looks like an incredibly painful interface. How about scrapping all
>of this _emu() mess and just reworking the register_cpu() interface?
> Something like:
hi, Paul
I saw your reply on patchwork.kernel.org, but I did not find your email
in my mailbox, you might forget to cc to me.
I think that your register_cpu_node interface seems good, but this will
remove the interface register_cpu. it is not the original purpose of the
emulator, we want to emulate the oringal process, but we did not want to change
the old interface, that is a rule.
I want to share some piece of codes, and I did not want to do so much change,
so I call register_cpu and register_cpu_emu in the same function. yes, it is a
painful interface, I will add a function arch_register_cpu_emu to solve it.
Real hotplug process:
arch_register_cpu
- call register_cpu
Emulated hotplug process:
arch_register_cpu_emu
- call register_cpu_emu
diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c
index 7e45159..93859d5 100644
--- a/arch/x86/kernel/topology.c
+++ b/arch/x86/kernel/topology.c
@@ -52,6 +52,16 @@ int __ref arch_register_cpu(int num)
}
EXPORT_SYMBOL(arch_register_cpu);
+/* emulated version for arch_register_cpu */
+int __ref arch_register_cpu_emu(int num, int nid)
+{
+ if (num)
+ per_cpu(cpu_devices, num).cpu.hotpluggable = 1;
+
+ return register_cpu_emu(&per_cpu(cpu_devices, num).cpu, nid);
+}
+EXPORT_SYMBOL(arch_register_cpu_emu);
+
void arch_unregister_cpu(int num)
{
unregister_cpu(&per_cpu(cpu_devices, num).cpu);
--
Thanks & Regards,
Shaohui
On Tue, Nov 16, 2010 at 12:13:30PM +0800, Shaohui Zheng wrote:
> >This looks like an incredibly painful interface. How about scrapping all
> >of this _emu() mess and just reworking the register_cpu() interface?
> > Something like:
>
> hi, Paul
> I saw your reply on patchwork.kernel.org, but I did not find your email
> in my mailbox, you might forget to cc to me.
>
Then fix your mailer. You are presently forcing Mail-Followup-To to the
list, which in turn is dropping you from the cc on a group reply.
> I think that your register_cpu_node interface seems good, but this will
> remove the interface register_cpu. it is not the original purpose of the
> emulator, we want to emulate the oringal process, but we did not want to change
> the old interface, that is a rule.
>
Wait, what? How does my patch remove register_cpu()? It does no such
thing, all it does is add a supplemental register_cpu_node() for you to
call in to, without needing to carry any of the _emu() damage around. The
old interface has not been modified in any way whatsoever.
>
> On Tue, Nov 16, 2010 at 12:13:30PM +0800, Shaohui Zheng wrote:
> > >This looks like an incredibly painful interface. How about scrapping all
> > >of this _emu() mess and just reworking the register_cpu() interface?
> > > Something like:
> >
> > hi, Paul
> > I saw your reply on patchwork.kernel.org, but I did not find your email
> > in my mailbox, you might forget to cc to me.
> >
> Then fix your mailer. You are presently forcing Mail-Followup-To to the
> list, which in turn is dropping you from the cc on a group reply.
My mailer is mutt, and I did not configure "Mail-Follow-To", it should use the
default value. I add "set followup_to=no" to my ~/muttrc file now.
Hope it is got fixed, thanks you for your remind.
>
> > I think that your register_cpu_node interface seems good, but this will
> > remove the interface register_cpu. it is not the original purpose of the
> > emulator, we want to emulate the oringal process, but we did not want to change
> > the old interface, that is a rule.
> >
> Wait, what? How does my patch remove register_cpu()? It does no such
> thing, all it does is add a supplemental register_cpu_node() for you to
> call in to, without needing to carry any of the _emu() damage around. The
> old interface has not been modified in any way whatsoever.
I recheck your patch, It seems that I misunderstand it. with your function
register_cpu_node, we can call it in arch_cpu_probe, and then we need not the _emu()
any more. Our _emu() functions work, but it get thing complicated. :)
I will rework patch 4 and patch 5 with your suggestion, thanks.
--
Thanks & Regards,
Shaohui
On Tue, Nov 16, 2010 at 01:05:07PM +0800, Shaohui Zheng wrote:
> >
> > On Tue, Nov 16, 2010 at 12:13:30PM +0800, Shaohui Zheng wrote:
> > > >This looks like an incredibly painful interface. How about scrapping all
> > > >of this _emu() mess and just reworking the register_cpu() interface?
> > > > Something like:
> > >
> > > hi, Paul
> > > I saw your reply on patchwork.kernel.org, but I did not find your email
> > > in my mailbox, you might forget to cc to me.
> > >
> > Then fix your mailer. You are presently forcing Mail-Followup-To to the
> > list, which in turn is dropping you from the cc on a group reply.
>
> My mailer is mutt, and I did not configure "Mail-Follow-To", it should use the
> default value. I add "set followup_to=no" to my ~/muttrc file now.
>
> Hope it is got fixed, thanks you for your remind.
>
Yes, it's fixed now!
> > > I think that your register_cpu_node interface seems good, but this will
> > > remove the interface register_cpu. it is not the original purpose of the
> > > emulator, we want to emulate the oringal process, but we did not want to change
> > > the old interface, that is a rule.
> > >
> > Wait, what? How does my patch remove register_cpu()? It does no such
> > thing, all it does is add a supplemental register_cpu_node() for you to
> > call in to, without needing to carry any of the _emu() damage around. The
> > old interface has not been modified in any way whatsoever.
>
> I recheck your patch, It seems that I misunderstand it. with your function
> register_cpu_node, we can call it in arch_cpu_probe, and then we need not the _emu()
> any more. Our _emu() functions work, but it get thing complicated. :)
>
> I will rework patch 4 and patch 5 with your suggestion, thanks.
>
Perhaps the easiest is just to insert my patch in to your series as a
standalone thing and then build on top of it for your patches 4 and 5. If
you wish to do this, then you can of course add my Signed-off-by for
that.
Also, are you doing this development in a git tree somewhere? I'd like to
get it going on top of SH also, so it would be nice to have a point of
reference for keeping things in sync (otherwise I'll just make a topic
branch with your newest version and send you updates incrementally).
> Perhaps the easiest is just to insert my patch in to your series as a
> standalone thing and then build on top of it for your patches 4 and 5. If
> you wish to do this, then you can of course add my Signed-off-by for
> that.
>
> Also, are you doing this development in a git tree somewhere? I'd like to
> get it going on top of SH also, so it would be nice to have a point of
> reference for keeping things in sync (otherwise I'll just make a topic
> branch with your newest version and send you updates incrementally).
It is an internal project, so we did not have a public git tree. it is available
in internal only.
the purpose of the emulator is just for CPU/Memory hotplug debuging, there are
a lot of hotplug issues before linux kernel 2.6.32, it is very hard to debug.
With the help of emuatlor, we get them fixed, so we think the emulator is a good
tool, and we want to share it with more people.
--
Thanks & Regards,
Shaohui