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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
