From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Sun, 03 Feb 2002 01:59:41 +0000 Subject: Re: Hot Plug I/O Node spec 0.2.1 Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Interesting ... > IO Node Hot Plug Design Notes > ==============> > Revision 0.2.1 > by Hiroshi Aono (h-aono@ap.jp.nec.com) [ deletia ] > 1.2. IO node > > Expected system layout: > > +---+ +---+ > |CPU|...|CPU| > +---+ +---+ > | | > +-----------+ > | PS | > +-----------+ > -> | | <- Hot-pluggable > +---+ +---+ > |ION|...|ION| > +---+ +---+ > > PS: PortSwitch > ION: IO Node > > Figure 1 Hot-pluggable System > ---------------------------- > > An IO node can be hot-pluggable between the PS (Port Switch) and IO > node. An IO node consists of IO bridges, interrupt controllers, some PCI > buses, many PCI slots and so on. > > IONode > +-----------------------------------------------+ > | BRIDGE0 BRIDGE1 ...... | > |+-------------------------+ +---------+ | > || +-------+ | | | | > || |IOSAPIC| | | | | > || +-------+ | | | | > || PCIBUS0 PCIBUS1 ..... | | | | > ||| --+-- || --+--SLOT | | | | > ||| --+-- || --+--SLOT | | | | > ||| --+-- || --+-- | | | | | > ||| --+-- || --+-- | | | | | > ||+-------++-------+ | | | | > |+-------------------------+ +---------+ | > +-----------------------------------------------+ > > Figure 2 IO Node > --------------- > > The BRIDGE is not only a PCI bridge but also next generation IO bridges > such as Infiniband, 3GIO and so on. So presumably you'll be looking at hotplug support for those other kinds of bridge and device, though perhaps not right away. That's good. > 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. 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. > 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). > 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. > IO node hotplug hierarchical structure will be as follows: > > --+ ionodeXX > + bridgeXX > + slotXX > + slotXX > + pic > + bridgeYYY > + slotYY > + slotYY > + pic > > Each node is a directory, and they have following files: > > o adapter > o attention > o latch > o power > o test > > 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? - Dave _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel