[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52AA7760.20603@jp.fujitsu.com>
Date: Fri, 13 Dec 2013 11:56:32 +0900
From: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
CC: ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux PCI <linux-pci@...r.kernel.org>,
"Moore, Robert" <robert.moore@...el.com>,
Toshi Kani <toshi.kani@...com>,
Yinghai Lu <yinghai@...nel.org>,
Zhang Rui <rui.zhang@...el.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Aaron Lu <aaron.lu@...el.com>, Lv Zheng <lv.zheng@...el.com>
Subject: Re: [PATCH 7/10] ACPI / hotplug: Move container-specific code out
of the core
Hi Rafael,
Please share your more detailed idea. I started to implement the following
idea. But the idea has one problem.
>>> The eject work flow can be:
>>> (1) an eject event occurs,
>>> (2) the container "physical" device fails offline in acpi_scan_hot_remove()
>>> emmitting, say, KOBJ_CHANGE for the "physical" device,
>>> (3) user space notices the KOBJ_CHANGE and does the cleanup as needed,
>>> (4) user space changes the "physical" container device flag controlling
>>> offline to 0,
>>> (5) user space uses the sysfs "eject" attribute of the ACPI container object
>>> to finally eject the container,
>>> (6) the offline in acpi_scan_hot_remove() is now successful, because the
>>> flag controlling it has been set to 0 in step (4),
>>> (7) the "physical" container device goes away before executing _EJ0,
>>> (8) the container is ejected.
I want to emit KOBJ_CHANGE before offlining devices on container device at (2).
But acpi_scan_hot_remove() offlines devices on container device at first.
So when offline container device, devices on container has been offlined.
Thus the idea cannot fulfill my necessary feature.
Thanks,
Yasauaki Ishimatsu
Thanks,
Yasauaki Ishimatsu
>>>
>>> Of course, if the flag controlling container offline is 0 to start with, step
>>> (6) will now occur directly after (1), so whoever wants containers to be
>>> hot-removed automatically may just clear that flag for all of them on boot.
>>>
>>> How does that sound?
>>
>>
>> The above ideas are almost O.K. I want kernel to notify user space of KOBJ_OFFLINE.
>> Even if user space catches "KOBJ_CHANGE", user doesn't know whether the notification
>> is offline or not.
>
> It is easy to figure out, though. Since the KOBJ_CHANGE will be emitted for
> container devices only in that situation, user space can see that (1) it is
> from a container and (2) it is KOBJ_CHANGE, so it must mean "container offline
> has been attempted".
>
> My concern with using KOBJ_OFFLINE for that is that device_offline() emits it
> too on success and it may be easily confused with the one emitted on failure
> for containers.
>
> Thanks,
> Rafael
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists