[RFC] New sysfs tree for hotplug

From: Keiichiro Tokunaga
Date: Thu Apr 15 2004 - 03:13:04 EST


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/:

/sys/bus/pci/slots/<slot#>/<files>

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
directory.

/sys/devices/system/


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:

/sys/devices/hotplug

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

/sys/devices/hotplug/acpi
/sys/devices/hotplug/dlpar

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,
like:

/sys/devices/hotplug/acpi/DEV1

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

/sys/devices/hotplug/acpi/DEV1/eject

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.

/sys/devices/hotplug/acpi/DEV2/DEV1/eject
(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:

sys/devices/hotplug/acpi/
`-DEV1/
|-eject
|
|-DEV3/
| `-eject
|
`-DEV4/
`-DEV6/
`-eject


Any comments or questions are welcomed.


Thanks,
Kei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/