From: Greg KH <gregkh@linuxfoundation•org>
To: "Rafael J. Wysocki" <rjw@sisk•pl>
Cc: linux-s390@vger•kernel.org, Toshi Kani <toshi.kani@hp•com>,
jiang.liu@huawei•com, wency@cn•fujitsu.com,
linux-acpi@vger•kernel.org, yinghai@kernel•org,
linux-kernel@vger•kernel.org, linux-mm@kvack•org,
isimatu.yasuaki@jp•fujitsu.com, srivatsa.bhat@linux•vnet.ibm.com,
guohanjun@huawei•com, bhelgaas@google•com,
akpm@linux-foundation•org, linuxppc-dev@lists•ozlabs.org,
lenb@kernel•org
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Sat, 2 Feb 2013 15:58:01 +0100 [thread overview]
Message-ID: <20130202145801.GB1434@kroah.com> (raw)
In-Reply-To: <1987042.JQv02Zsfg5@vostro.rjw.lan>
On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > > them, or give me a _really_ good reason why they will not work.
> > > >
> > > > We cannot use the existing system devices or ACPI devices here. During
> > > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > > device information in a platform-neutral way. During hot-add, we first
> > > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > > but platform-neutral modules cannot use them as they are ACPI-specific.
> > >
> > > But suppose we're smart and have ACPI scan handlers that will create
> > > "physical" device nodes for those devices during the ACPI namespace scan.
> > > Then, the platform-neutral nodes will be able to bind to those "physical"
> > > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > > this way that will reflect all of the dependencies we need to take into
> > > account during hot-add and hot-remove operations. That may not be what we
> > > have today, but I don't see any *fundamental* obstacles preventing us from
> > > using this approach.
> >
> > I would _much_ rather see that be the solution here as I think it is the
> > proper one.
> >
> > > This is already done for PCI host bridges and platform devices and I don't
> > > see why we can't do that for the other types of devices too.
> >
> > I agree.
> >
> > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > when we try do eject a device at the top of a subtree and need to tear down
> > > the entire subtree below it, but if that's going to lead to a system crash,
> > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > help from the driver core here.
> >
> > I say do what we always have done here, if the user asked us to tear
> > something down, let it happen as they are the ones that know best :)
> >
> > Seriously, I guess this gets back to the "fail disconnect" idea that the
> > ACPI developers keep harping on. I thought we already resolved this
> > properly by having them implement it in their bus code, no reason the
> > same thing couldn't happen here, right?
>
> Not really. :-) We haven't ever resolved that particular issue I'm afraid.
Ah, I didn't realize that.
> > I don't think the core needs to do anything special, but if so, I'll be glad
> > to review it.
>
> OK, so this is the use case. We have "eject" defined for something like
> a container with a number of CPU cores, PCI host bridge, and a memory
> controller under it. And a few pretty much arbitrary I/O devices as a bonus.
>
> Now, there's a button on the system case labeled as "Eject" and if that button
> is pressed, we're supposed to _try_ to eject all of those things at once. We
> are allowed to fail that request, though, if that's problematic for some
> reason, but we're supposed to let the BIOS know about that.
>
> Do you seriously think that if that button is pressed, we should just proceed
> with removing all that stuff no matter what? That'd be kind of like Russian
> roulette for whoever pressed that button, because s/he could only press it and
> wait for the system to either crash or not. Or maybe to crash a bit later
> because of some delayed stuff that would hit one of those devices that had just
> gone. Surely not a situation any admin of a high-availability system would
> like to be in. :-)
>
> Quite frankly, I have no idea how that can be addressed in a single bus type,
> let alone ACPI (which is not even a proper bus type, just something pretending
> to be one).
You don't have it as a single bus type, you have a controller somewhere,
off of the bus being destroyed, that handles sending remove events to
the device and tearing everything down. PCI does this from the very
beginning.
I know it's more complicated with these types of devices, and I think we
are getting closer to the correct solution, I just don't want to ever
see duplicate devices in the driver model for the same physical device.
thanks,
greg k-h
next prev parent reply other threads:[~2013-02-02 14:56 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 23:40 [RFC PATCH v2 00/12] System device hot-plug framework Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Toshi Kani
2013-01-11 21:23 ` Rafael J. Wysocki
2013-01-14 15:33 ` Toshi Kani
2013-01-14 18:48 ` Rafael J. Wysocki
2013-01-14 19:02 ` Toshi Kani
2013-01-30 4:48 ` Greg KH
2013-01-31 1:15 ` Toshi Kani
2013-01-31 5:24 ` Greg KH
2013-01-31 14:42 ` Toshi Kani
2013-01-30 4:53 ` Greg KH
2013-01-31 1:46 ` Toshi Kani
2013-01-30 4:58 ` Greg KH
2013-01-31 2:57 ` Toshi Kani
2013-01-31 20:54 ` Rafael J. Wysocki
2013-02-01 1:32 ` Toshi Kani
2013-02-01 7:30 ` Greg KH
2013-02-01 20:40 ` Toshi Kani
2013-02-01 22:21 ` Rafael J. Wysocki
2013-02-01 23:12 ` Toshi Kani
2013-02-02 15:01 ` Greg KH
2013-02-04 0:28 ` Toshi Kani
2013-02-04 12:46 ` Greg KH
2013-02-04 16:46 ` Toshi Kani
2013-02-04 19:45 ` Rafael J. Wysocki
2013-02-04 20:59 ` Toshi Kani
2013-02-04 23:23 ` Rafael J. Wysocki
2013-02-04 23:33 ` Toshi Kani
2013-02-01 7:23 ` Greg KH
2013-02-01 22:12 ` Rafael J. Wysocki
2013-02-02 14:58 ` Greg KH [this message]
2013-02-02 20:15 ` Rafael J. Wysocki
2013-02-02 22:18 ` [PATCH?] Move ACPI device nodes under /sys/firmware/acpi (was: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework) Rafael J. Wysocki
2013-02-04 1:24 ` Greg KH
2013-02-04 12:34 ` Rafael J. Wysocki
2013-02-03 20:44 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Rafael J. Wysocki
2013-02-04 12:48 ` Greg KH
2013-02-04 14:21 ` Rafael J. Wysocki
2013-02-04 14:33 ` Greg KH
2013-02-04 20:07 ` Rafael J. Wysocki
2013-02-04 22:13 ` Toshi Kani
2013-02-04 23:52 ` Rafael J. Wysocki
2013-02-05 0:04 ` Greg KH
2013-02-05 1:02 ` Rafael J. Wysocki
2013-02-05 11:11 ` Rafael J. Wysocki
2013-02-05 18:39 ` Greg KH
2013-02-05 21:13 ` Rafael J. Wysocki
2013-02-05 0:55 ` Toshi Kani
2013-02-04 16:19 ` Toshi Kani
2013-02-04 19:43 ` Rafael J. Wysocki
2013-02-04 1:23 ` Greg KH
2013-02-04 13:41 ` Rafael J. Wysocki
2013-02-04 16:02 ` Toshi Kani
2013-02-04 19:48 ` Rafael J. Wysocki
2013-02-04 19:46 ` Toshi Kani
2013-02-04 20:12 ` Rafael J. Wysocki
2013-02-04 20:34 ` Toshi Kani
2013-02-04 23:19 ` Rafael J. Wysocki
2013-01-10 23:40 ` [RFC PATCH v2 02/12] ACPI: " Toshi Kani
2013-01-11 21:25 ` Rafael J. Wysocki
2013-01-14 15:53 ` Toshi Kani
2013-01-14 18:47 ` Rafael J. Wysocki
2013-01-14 18:42 ` Toshi Kani
2013-01-14 19:07 ` Rafael J. Wysocki
2013-01-14 19:21 ` Toshi Kani
2013-01-30 4:51 ` Greg KH
2013-01-31 1:38 ` Toshi Kani
2013-01-14 19:21 ` Greg KH
2013-01-14 19:29 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 03/12] drivers/base: Add " Toshi Kani
2013-01-30 4:54 ` Greg KH
2013-01-31 1:48 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 04/12] cpu: Add cpu hotplug handlers Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 05/12] mm: Add memory " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 06/12] ACPI: Add ACPI bus " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 07/12] ACPI: Add ACPI resource hotplug handler Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 08/12] ACPI: Update processor driver for hotplug framework Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 09/12] ACPI: Update memory " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 10/12] ACPI: Update container " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 11/12] cpu: Update sysfs cpu/online " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 12/12] ACPI: Update sysfs eject " Toshi Kani
2013-01-17 0:50 ` [RFC PATCH v2 00/12] System device hot-plug framework Rafael J. Wysocki
2013-01-17 17:59 ` Toshi Kani
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=20130202145801.GB1434@kroah.com \
--to=gregkh@linuxfoundation$(echo .)org \
--cc=akpm@linux-foundation$(echo .)org \
--cc=bhelgaas@google$(echo .)com \
--cc=guohanjun@huawei$(echo .)com \
--cc=isimatu.yasuaki@jp$(echo .)fujitsu.com \
--cc=jiang.liu@huawei$(echo .)com \
--cc=lenb@kernel$(echo .)org \
--cc=linux-acpi@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=rjw@sisk$(echo .)pl \
--cc=srivatsa.bhat@linux$(echo .)vnet.ibm.com \
--cc=toshi.kani@hp$(echo .)com \
--cc=wency@cn$(echo .)fujitsu.com \
--cc=yinghai@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox