On Thu, 2013-01-17 at 01:50 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 10, 2013 04:40:18 PM Toshi Kani wrote:
> > This patchset is a prototype of proposed system device hot-plug framework
> > for design review. Unlike other hot-plug environments, such as USB and
> > PCI, there is no common framework for system device hot-plug [1].
> > Therefore, this patchset is designed to provide a common framework for
> > hot-plugging and online/offline operations of system devices, such as CPU,
> > Memory and Node. While this patchset only supports ACPI-based hot-plug
> > operations, the framework itself is designed to be platform-neural and
> > can support other FW architectures as necessary.
:
> At this point I'd like to clearly understand how the code is supposed to work.
Thanks for reviewing!
> From what I can say at the moment it all boils down to having two (ordered)
> lists of notifiers (shp_add_list, shp_del_list) that can be added to or
> removed
> from with shp_register_handler() and shp_unregister_handler(), respectively
Yes.
> (BTW, the abbreviation "hdr" makes me think about a "header" rather than a
> "handler", but maybe that's just me :-)),
Well, it makes me think that way as well. :) How about "hdlr"?
> and a workqueue for requests (why do
> we need a separate workqueue for that?).
This workqueue needs to be platform-neutral and max_active set to 1, and
preferably is dedicated for hotplug operations. kacpi_hotplug_wq is
close, but is ACPI-specific. So, I decided to create a new workqueue
for this framework.
> Whoever needs to carry out a hotplug operation is supposed to prepare a
> request
> and then put it into the workqueue with shp_submit_request(). The framework
> will then execute all of the notifier callbacks from the appropriate notifier
> list (depending on whether the operation is a hot-add or a hot-remove). If
> any
> of those callbacks returns an error code and it is not too late (the order of
> the failing notifier is not too high), the already executed notifier callbacks
> will be run again with the "rollback" argument set to 1 (why not to use bool?)
Agreed. I will change the rollback to bool.
> to indicate that they are supposed to bring things back to the initial state.
> Error codes returned in that stage only cause messages to be printed.
>
> Is the description above correct?
Yes. It's very good summary!
> If so, it looks like subsystems are supposed to register notifiers (handlers)
> for hotplug/hot-remove operations of the devices they handle. They are
> supposed to use predefined order values to indicate what kinds of devices
> those are. Then, hopefully, if they do everything correctly, and the
> initiator of a hotplug/hot-remove operation prepares the request correctly,
> the callbacks will be executed in the right order, they will find their
> devices in the list attached to the request object and they will do what's
> necessary with them.
>
> Am I still on the right track?
Yes.
> If that's the case, I have a few questions.
Well, there are more than a few :), but they all are excellent
questions!
> (1) Why is this limited to system devices?
It could be extended to other devices, but is specifically designed for
system devices as follows. So, I think it is best to keep it in that
way.
a) Work with multiple subsystems without bus dependency. Other hot-plug
frameworks are designed and implemented for a particular bus and a
subsystem. Therefore, they work best for their targeted environment as
well.
b) Sequence with pre-defined order. This allows hot-add operation and
the boot sequence to be consistent. Other non-system devices are
initialized within a subsystem, and do not depend on the boot-up
sequence.
> (2) What's the guarantee that the ordering of hot-removal (for example) of CPU
> cores with respect to memory and host bridges will always be the same?
> What if the CPU cores themselves need to be hot-removed in a specific
> order?
When devices are added in the order of A->B->C, their dependency model
is:
- B may depend on A (but A may not depend on B)
- C may depend on A and B (but A and B may not depend on C)
Therefore, they can be deleted in the order of C->B->A.
The boot sequence defines the order for add. So, it is important to
make sure that we hot-add devices in the same order with the boot
sequence. Of course, if there is an issue in the order, we need to fix
it. But the point is that the add order should be consistent between
the boot sequence and hot-add.
In your example, the boot sequence adds them in the order of
memory->CPU->host bridge. I think this makes sense because cpu may need
its local memory, and host bridge may need its local memory and local
cpu for interrupt. So, hot-add needs to do the same for node hot-add,
and hot-delete should be able to delete them in the reversed order per
their dependency model.
> (3) What's the guarantee that the ordering of shp_add_list and shp_del_list
>
