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.
> 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.
> 3. Why can't initialize the system devices from the driver structure at
> boot?
> The driver structure is initialized at the end of the boot sequence and
> requires the low-level services from the system devices initialized
> beforehand.
Wait, what "driver structure"? 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.
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...
> 4. Why do we need a new common framework?
> Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> and memory modules. They are common code and do not depend on ACPI.
> Therefore, a new common framework is necessary to integrate both
> on-lining/off-lining operation and hot-plugging operation of system
> devices into a single framework.
{sigh}
Removing and adding devices and handling hotplug operations is what the
driver core was written for, almost 10 years ago. To somehow think that
your devices are "special" just because they don't use ACPI is odd,
because the driver core itself has nothing to do with ACPI. Don't get
the current mix of x86 system code tied into ACPI confused with an
driver core issues here please.
> 5. Why can't do everything with ACPI bus scan?
> Software dependency among system devices may not be dictated by the ACPI
> hierarchy. For instance, memory should be initialized before CPUs (i.e.
> a new cpu may need its local memory), but such ordering cannot be
> guaranteed by the ACPI hierarchy. Also, as described in 4,
> online/offline operations are independent from ACPI.
That's fine, the driver core is independant from ACPI. I don't care how
you do the scaning of your devices, but I do care about you creating new
driver core pieces that duplicate the existing functionality of what we
have today.
In short, I like Rafael's proposal better, and I fail to see how
anything you have stated here would matter in how this is implemented. :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
