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.
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