From: joeyli <jlee@suse.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Subject: Re: A udev rule to serve the change event of ACPI container?
Date: Thu, 3 Aug 2017 17:52:57 +0800 [thread overview]
Message-ID: <20170803095257.GD5730@linux-l9pv.suse> (raw)
In-Reply-To: <20170803093153.GG12521@dhcp22.suse.cz>
On Thu, Aug 03, 2017 at 11:31:53AM +0200, Michal Hocko wrote:
> On Thu 03-08-17 17:22:37, Joey Lee wrote:
> > On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote:
> > > On Mon 31-07-17 15:38:45, Joey Lee wrote:
> [...]
> > > > So, the behavior is:
> > > >
> > > > Kernel received ejection event, set _Eject_ flag on container object
> > > > -> Kernel sends offline events to all children devices
> > > > -> User space performs cleaning jobs and offlines each child device
> > > > -> Kernel detects all children offlined
> > > > -> Kernel removes objects and calls power off(_EJ0)
> > >
> > > Yes this is what I've had in mind. It is the "kernel detects..." part
> > > which is not implemented now and that requires us to do the explicit
> > > eject from userspace, correct?
> > >
> >
> > Yes, the _Eject_ flag and _detects_ part are not implemented now.
> >
> > In this approach, kernel still relies on user space to trigger the
> > offline. The ejection process is still not transparent to user space.
> > Is it what you want?
>
> But as long as there is no auto-offlining then there is no other choice
> no? Besides that userspace even shouldn't care about the fact that the
If Yasuaki's problem is already fixed in mainline, then the auto-offlining
will be possible.
> eject is in progress. That is a BIOS->OS deal AFAIU. All the userspace
> cares about is the proper cleanup of the resources and that happens at
> the offline time.
>
I agree! User space doesn't need to know the detail of kobject cleaning
and ejection stages.
> > > > If anyone onlined one of the children devices in the term of waiting
> > > > userland offlines all children, then the _Eject_ flag will be clean
> > > > and ejection process will be interrupted. In this situation, administrator
> > > > needs to trigger ejection event again.
> > >
> > > yes
> > >
> > > > Do you think that the race hurts anything?
> > >
> > > What kind of race?
> >
> > User space set a child online before all childreen offlined, then
> > the _Eject_ flag is cleaned and the ejection process is interrupted.
>
> Is this really a race though? Kernel will always have a full picture and
> if userspace wants to online some part then the eject cannot succeed.
> This is something that a userspace driver eject cannot possibly handle.
Then I agree.
I am waiting Yasuaki's response and want to know Rafael's and
Yasuaki's opinions about the _Eject_ flag approach.
Thanks a lot!
Joey Lee
next prev parent reply other threads:[~2017-08-03 9:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-26 6:26 A udev rule to serve the change event of ACPI container? joeyli
2017-06-26 8:59 ` Michal Hocko
2017-07-11 8:25 ` Michal Hocko
2017-07-13 6:58 ` joeyli
2017-07-13 7:06 ` Michal Hocko
2017-07-13 12:45 ` joeyli
2017-07-14 8:37 ` Michal Hocko
2017-07-14 14:44 ` joeyli
2017-07-17 9:05 ` Michal Hocko
2017-07-19 9:09 ` joeyli
2017-07-24 8:57 ` Michal Hocko
2017-07-24 9:29 ` joeyli
2017-07-25 12:48 ` Michal Hocko
2017-07-31 7:38 ` joeyli
2017-08-02 9:01 ` Michal Hocko
2017-08-03 9:22 ` joeyli
2017-08-03 9:31 ` Michal Hocko
2017-08-03 9:52 ` joeyli [this message]
2017-08-03 11:25 ` Michal Hocko
2017-07-23 9:18 ` joeyli
2017-08-01 19:21 ` YASUAKI ISHIMATSU
2017-08-02 5:49 ` joeyli
2017-08-03 15:37 ` YASUAKI ISHIMATSU
2017-08-04 15:06 ` Michal Hocko
2017-08-15 10:04 ` joeyli
2017-06-28 19:53 ` YASUAKI ISHIMATSU
2017-06-29 3:57 ` joeyli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170803095257.GD5730@linux-l9pv.suse \
--to=jlee@suse.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=rafael.j.wysocki@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.