Re: Re : [PATCH] acpi: Fix hot cpu remove problem on acpi subsystem

[canquan.shen]

On 2011/9/7 14:57, Bjorn Helgaas wrote:
> On Tue, Sep 6, 2011 at 7:40 PM, canquan.shen<shencanquan@xxxxxxxxxx>  wrote:
> > On 2011/9/7 2:38, Bjorn Helgaas wrote:
>
> > > Is acpi_processor_remove() called when you remove a processor?  I see
> > > a path where it will be called via acpi_eject_store():
> > >
> > >      acpi_eject_store
> > >        acpi_os_hotplug_execute(acpi_bus_hot_remove_device)
> > >        acpi_bus_hot_remove_device
> > >          acpi_bus_trim
> > >            acpi_bus_remove
> > >              device_release_driver
> > >                dev->driver->remove (acpi_processor_remove())
> > >              acpi_device_unregister
> > >                device_unregister
> > >                  device_del
> > >                    kobject_uevent(KOBJ_REMOVE)
> > >
> > > but as far as I can tell, this path is only used when we write
> > > something to the "eject" sysfs file.  I would think we'd want to use
> > > most of this same path when we hot remove a CPU via the ACPI SCI
> > > mechanism.
> >
> > Because in my patch will send the KOBJ_REMOVE event to udev module. and I
> > write a udev rule like the following:
> > ACTION=="remove",DRIVER=="processor",SUBSYSTEM=="acpi",RUN+="/bin/bash -c
> > 'echo 1>  /sys%p/eject'"
> > This rule will write "1" to the "eject" sysfs file. and then call
> > acpi_eject_store function.
>
> Hmmm.  I think I understand your proposal, but it seems like a
> convoluted path to me.
>
> I guess the real question is whether we must give userspace a chance
> to decide whether to actually do the remove or not.  Is there a
> requirement to do that?  Neither the dynamic device removal flow (ACPI
> spec 4.0a, sec 6.3) nor the ejection flow example (fig 6-5) mentions
> doing that.
   I think we should give userspace a chance to decide whether do  the 
remove or not. About the cpu remove, it has two part, one in the linux 
kernel which mainly online/offline cpu, another is acpi core driver, 
which mainly add and remove the device of processor.
   giving userspace a chance is not acpi spec requirement. but it is 
flexible for linux kernel. many driver use the udev mechanism to has a 
chance for user to decide how to handle the event of kernel.

> I mentioned before that I think the ACPI hotplug code should be ripped
> out of the drivers and consolidated in the ACPI core.  I think it's
> pretty clear from the spec that the 0-0x7f notifications (Bus Check,
> Device Check, Eject Request, etc.) are designed to be handled by the
> core, not by individual drivers.  We handle hotplug in the drivers
> today, but I think that's mainly because we never implemented support
> in the Linux ACPI core.  There are comments in acpi_bus_check_device()
> and acpi_bus_check_scope() about what we *should* be doing there.
>
> I am opposed to adding more hotplug support to individual drivers
> because I still hope that someday we'll support it in the ACPI core.
> Many ACPI drivers don't support hotplug at all, and the ones that do
> support hotplug do it in a variety of ways.  It's all quite a mess.
>
> Bjorn
>
> .

I admit it is convoluted path for hot cpu remove. and the acpi processor 
driver will be consolidated in the acip core. but how to do in the acpi 
core ? I think it maybe directly call acpi_bus_hot_remove_device or send 
KOBJ_OFFLINE event to linux kernel.

I will modify the processor driver by add the acpi_bus_trim function in 
acpi_processor_hotplug_notify. and create the patch for fix this problem.
Could you help me to merge to latest linux kernel? Thanks for your 
answer again.

---
canquan.shen





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/