Hot Plug I/O Node spec 0.2.1
Quoted 5 lines · David Brownell
Quoted 4 lines
Both hot-plugging and the removal of interfaces between OS and hardware is mainly performed by ACPI. When insertion or removal of an IO node, a single interrupt (calls SCI) is generated.
Quoted 7 lines
Must it work this way -- depending on ACPI? I know there's a fair degree of discomfort with the notion of needing to depend on traditionally flakey BIOS level code. (I'd make a similar comment for other BIOS dependencies described in this 0.2.1 draft.) My understanding is that folk would rather rely on open hardware specs for the Linux kernel, since it's shown to lead to more robust and reliable systems.
Unfortunatly, for ia64 machines, PCI Hotplug functionality is usually done through ACPI. NEC's ia64 machines are this way, as is IBM's. There is nothing we can do about this (belive me, I tried...)
Actually, in the end, it makes the driver a lot simpler. Hiroshi has modified my pcihp_acpi framework to initially work with his machines, and the ammount of code is much smaller than the existing Compaq pci hotplug driver, or the IBM pci hotplug driver, where we have direct access to the controller.
Now there is the problem of different people implementing ACPI PCI information in different ways, but that's a problem that we are going to have to work around. Even with this problem, we can share lots of code (I'm going to post an updated driver soon, based on Hiroshi's patch, which shows this.)
Quoted 9 lines
Quoted 4 lines
2.1. Domain Resource Manager
The IO node manager has an interface to communicate with the Domain Resource Manager. We will have to decide the details of the interface.
This would be a Linux component I happen not to have heard of.
Is it perhaps an ACPI component? It'd be good to see a pointer
to this (as well as the ATLAS project you mentioned, and all the other components referenced here).
The Atlas "project" can be found at:
http://foundries.sourceforge.net/large/
It has links to most all of the different specific projects that fall under the "Atlas" project umbrella.
Quoted 11 lines
Quoted 7 lines
3.3. Hotplug Filesystem
We'd like to use the hotplug filesystem. This is for PCI hotplug filesystem and we feel this is most suitable for the generic hotplug interface. The hotplug filesystem will be used for user interfaces. We will improve this to treat a hierarchical structure for describing IO node objects.
So far, nobody else has felt a need for a hotplug filesystem. It'd be interesting to know the "user interfaces" you're thinking about, and why a new filesystem might be needed.
Um, take a look at pcihpfs in the 2.4 and 2.5 kernels. It's the user interface between the pci hotplug controller and userspace, and is already in the kernel.
I would have used driverfs if it was present in 2.4, but it wasn't. So I copied all of Pat's code, and created pcihpfs :)
Quoted 20 lines
Quoted 20 lines
IO node hotplug hierarchical structure will be as follows:
--+ ionodeXX
+ bridgeXX
+ slotXX
+ slotXX
+ pic
+ bridgeYYY
+ slotYY
+ slotYY
+ picEach node is a directory, and they have following files:
o adapter
o attention
o latch
o power
o test
Quoted 4 lines
Quoted 1 line
These files are used for controlling hotplug functions.
Hmm, sounds like maybe the 2.5 "driverfs" is more appropriate than a "hotplug filesystem". Is that what you meant?
No, the existing pcihpfs does not have the "bridge" directories, but only slots. This is a proposal to add this.
I do not think this needs to be added. The current slot name should allow you to show the bridge name if you wish. Since you can't have more than 256 slots in a system right now, I don't see the need to add the bridge abstraction.
thanks,
greg k-h
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel