Re: [Pcihpd-discuss] Re: Hot Plug I/O Node spec 0.2.1

[Greg KH <greg@kroah.com>]

On Sat, Feb 02, 2002 at 05:59:41PM -0800, David Brownell wrote:
> 
> > 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.

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

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

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

> > 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?

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel