[RFC] New sysfs tree for hotplug

From: Keiichiro Tokunaga <tokunaga.keiich_at_jp.fujitsu.com>
Date: 2004-04-15 18:09:39
Hi hotplug folks,

I'm interested in hotplug features, especially physical insertion/removal.  I'd
like to propose here a new sysfs tree for hotplug.  Please comment on my
proposal, because this is a request for comments:-)

1. Current sysfs for hotplug
 In 2.6, there are some sysfs files for hotplug.  For instance, PCI has that
kind of files to control hotplug features.  PCI related sysfs entries for hotplug
are created under /sys/bus/pci/slots/:


There are some files under <slot#> directory.  Some of them are supposed
to expose kenrel information, the others are supposed to control hotplug.
Recently, CPU and memory hotplug are being worked actively.  According 
to their patch, they seem to be trying to create sysfs files under the following


2. Problem
 Recent large machines have many PCI devices and some boards that
contain devices (e.g. CPU, memory, and/or I/O devices).  A certain PCI
device (PCI1) might be connected with other one (PCI2), which means that
there is a dependency between PCI1 and PCI2.  Similarly, there is a 
dependency between the board and devices attached on the board.
In this situation, we need to know the dependency first when we want to
hot-remove such devices or board.  However, I don't think that the flat sysfs
layout represents a dependency between each device quite well.

3. Suggestion
 To solve the problem, I'd like to propose the following idea.

["hotplug" directory]
   This directory is to represent a hierarchy of hotpluggable devices.
  "hotpluggable device" means a device that can be powered off and
  removed physically from the system running.  The hierarchy describes a 
  dependency between each device.  This directory would be placed, like:


  Any systems that enable hotplug (e.g. ACPI, DLPAR) can create their
  own directory right under the "hotplug" directory, like:


  Each of systems can create directories and files under the own directory,
  and these directories should be easy for user to use.

[ACPI based Hotplug Case]
   I think that ACPI is one of the systems tha know dependencies of devices.
  So, I'd like to show an example here how ACPI based hotplug can work
  under the "hotplug" directory.  (I still have a lot of things to think, though.)

  In ACPI based hotplug, "hotpluggable device" could be defined as follows:

      A device that its device object in ACPI namespace has _EJ0 and _STA
      method, and the _STA returns 0x0F (present).

      [Hotpluggable device (simplified ASL)]
        Scope (\_SB_) {
            Device (DEV1) {
                Method (_EJ0) {...}
                Method (_STA) {... return 0x0F}

  The above hotpluggable device is represented under the "hotplug" directory,


  Plus, a control file, "eject", which is used for invoking a corresponding
  device hot-removal handler, is created under each hotpluggable devices'
  directory, like:


  The directory "DEV1" and the file "eject" are deleted when the device is
  removed.  A point here is:

        While a device is attached to the system, a corresponding directory
        appears on sysfs.  When the device is removed from the system, the 
        directory is also deleted.

  As mentioned above, basically a directory is created only for hotpluggable
  devices.  However, there is a special case that a directory is created for
  devices that include a hotpluggable device.

      (where, DEV2 is not a hotpluggable device)

  In addition, the special directory is deleted when the child hotpluggable
  device is removed.

Let's take a look at a sample here.
Assume that you have a large machine containing many devices, and the
devices are defined in ACPI namespace like below.

    [Simplified ASL]
      Scope (\_SB_) {
          Device (DEV1) {
              Method (_EJ0) {...}
              Method (_STA, 0) { Return (0x0F) }

              Device (DEV2) {
                  Method (_STA, 0) { Return (0x0F) }

              Device (DEV3) {
                  Method (_EJ0) {...}
                  Method (_STA, 0) { Return (0x0F) }

              Device (DEV4) {
                  Method (_STA, 0) { Return (0x0F) }
                  Device (DEV5) {
                      Method (_EJ0) {...}
                      Method (_STA, 0) { Return (0x00) }
                  Device (DEV6) {
                      Method (_EJ0) {...}
                      Method (_STA, 0) { Return (0x0F) }

In this case, "hotplug" tree looks like:

            |   `-eject

Any comments or questions are welcomed.

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Apr 15 04:14:25 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:25 EST