linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Toshi Kani <toshi.kani@hp.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"isimatu.yasuaki@jp.fujitsu.com" <isimatu.yasuaki@jp.fujitsu.com>,
	"jiang.liu@huawei.com" <jiang.liu@huawei.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"guohanjun@huawei.com" <guohanjun@huawei.com>,
	"yinghai@kernel.org" <yinghai@kernel.org>,
	"srivatsa.bhat@linux.vnet.ibm.com"
	<srivatsa.bhat@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Sat, 2 Feb 2013 16:01:54 +0100	[thread overview]
Message-ID: <20130202150154.GC1434@kroah.com> (raw)
In-Reply-To: <1359751210.15120.278.camel@misato.fc.hp.com>

On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote:
> On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> >  > 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.
> > > > 
> > > > 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.
> > > 
> > > There are three different approaches suggested for system device
> > > hot-plug:
> > >  A. Proceed within system device bus scan.
> > >  B. Proceed within ACPI bus scan.
> > >  C. Proceed with a sequence (as a mini-boot).
> > > 
> > > Option A uses system devices as tokens, option B uses acpi devices as
> > > tokens, and option C uses resource tables as tokens, for their handlers.
> > > 
> > > Here is summary of key questions & answers so far.  I hope this
> > > clarifies why I am suggesting option 3.
> > > 
> > > 1. What are the system devices?
> > > System devices provide system-wide core computing resources, which are
> > > essential to compose a computer system.  System devices are not
> > > connected to any particular standard buses.
> > 
> > Not a problem, lots of devices are not connected to any "particular
> > standard busses".  All this means is that system devices are connected
> > to the "system" bus, nothing more.
> 
> Can you give me a few examples of other devices that support hotplug and
> are not connected to any particular buses?  I will investigate them to
> see how they are managed to support hotplug.

Any device that is attached to any bus in the driver model can be
hotunplugged from userspace by telling it to be "unbound" from the
driver controlling it.  Try it for any platform device in your system to
see how it happens.

> > > 2. Why are the system devices special?
> > > The system devices are initialized during early boot-time, by multiple
> > > subsystems, from the boot-up sequence, in pre-defined order.  They
> > > provide low-level services to enable other subsystems to come up.
> > 
> > Sorry, no, that doesn't mean they are special, nothing here is unique
> > for the point of view of the driver model from any other device or bus.
> 
> I think system devices are unique in a sense that they are initialized
> before drivers run.

No, most all devices are "initialized" before a driver runs on it, USB
is one such example, PCI another, and I'm pretty sure that there are
others.

> > If you need to initialize the driver
> > core earlier, then do so.  Or, even better, just wait until enough of
> > the system has come up and then go initialize all of the devices you
> > have found so far as part of your boot process.
> 
> They are pseudo drivers that provide sysfs entry points of cpu and
> memory.  They do not actually initialize cpu and memory.  I do not think
> initializing cpu and memory fits into the driver model either, since
> drivers should run after cpu and memory are initialized.

We already represent CPUs in the sysfs tree, don't represent them in two
different places with two different structures.  Use the existing ones
please.

> > None of the above things you have stated seem to have anything to do
> > with your proposed patch, so I don't understand why you have mentioned
> > them...
> 
> You suggested option A before, which uses system bus scan to initialize
> all system devices at boot time as well as hot-plug.  I tried to say
> that this option would not be doable.

I haven't yet been convinced otherwise, sorry.  Please prove me wrong :)

thanks,

greg k-h

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2013-02-02 15:10 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 [this message]
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
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=20130202150154.GC1434@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=guohanjun@huawei.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rjw@sisk.pl \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=toshi.kani@hp.com \
    --cc=wency@cn.fujitsu.com \
    --cc=yinghai@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox