Linas Vepstas writes: > Actually, no. There are three issues: > 1) hotplug routines are called from within kernel. GregKH has stated on > multiple occasions that doing this is wrong/bad/evil. This includes > calling hot-unplug. > > 2) As a result, the code to call hot-unplug is a bit messy. In > particular, there's a bit of hoop-jumping when hotplug is built as > as a module (and said hoops were wrecked recently when I moved the > code around, out of the rpaphp directory).
One way to clean this up would be to make rpaphp the driver for the EADS bridges (from the pci code's point of view). Then it would automatically get included in the error recovery process and could do whatever it should. > 3) Hot-unplug causes scripts to run in user-space. There is no way to > know when these scripts are done, so its not clear if we've waited > long enough before calling hot-add (or if waiting is even necessary). OK, so let's just add a new hotplug event called KOBJ_ERROR or something, which tells userspace that an error has occurred which has made the device inaccessible. Greg, would that be OK? The only trouble with that is that if we don't have a hotplug bridge driver loaded for the slot, we can't tell the driver that its device has gone away. I guess that's not a big problem in practice. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/