On Wed, Apr 20, 2005 at 11:26:28AM +0200, Molle Bestefich wrote: > David Greaves wrote: > > Guy wrote: > > > Well, I agree with KISS, but from the operator's point of view! > > > > > > I want... > > [snip] > > > > Fair enough. > [snip] > > should the LED control code be built into mdadm? > Obviously not. > But currently, a LED control app would have to pull information from > /proc/mdstat, right? > mdstat is a crappy place to derive any state from. > It currently seems to have a dual purpose: > - being a simple textual representation of RAID state for the user. > - providing MD state information for userspace apps. > That's not good. I could not agree more. > There seems to be an obvious lack of a properly thought out interface > to notify userspace applications of MD events (disk failed --> go > light a LED, etc). > Please correct me if I'm on the wrong track, in which case the rest of > this posting will be bogus. Maybe there are IOCTLs or such that I'm > not aware of. > I'm not sure how a proper interface could be done (so I'm basically > just blabbering). ACPI has some sort of event system, but the MD one > would need to be more flexible. For instance userspace apps has to > pick up on MD events such as disk failures, even if the userspace app > happens to not be running in the exact moment that the event occurs > (due to system restart, daemon restart or what not). So the system > that ACPI uses is probably unsuited. > Perhaps a simple logfile would do. No, as it requires active polling. I think something like a netlink device would be more accurate, but I'm not a kernel guru. Herve -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html