On Tue, Aug 23, 2016 at 01:10:18PM -0400, Keith Busch wrote: > On Tue, Aug 23, 2016 at 08:39:13AM -0500, Bjorn Helgaas wrote: > > On Mon, Aug 22, 2016 at 05:15:36PM -0400, Keith Busch wrote: > > > > The other IBPI states (fail, rebuild, predicted failure, hotspare, > > degraded, failed) all seem like storage-related things without an > > obvious connection to pciehp. I would expect a kernel driver like md > > to manage those states. > > Yes, that's fairly accurate on how this works with other storage > transports. While md doesn't directly affect LED states, 'ledmon' > subscribes to md events and executes an appropriate LED control method > specific to that transport. This is a tangent, but is there some reason for putting ledmon in the middle of this scheme? It seems like the important pieces (md and LED control) are intimately related and both in the kernel, so why the trip through userland? ledmon sounds like a glorified special-case /dev/mem, with similar security and stability issues. Plus it must have to associate a storage device with a PCIe port, grub through its config space to find the Slot Control register, deal with possible hotplug, etc. It all sounds icky. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
