Hi Keith, > > > >cat /sys/class/leds/0000:88:00.0::pcie_ssd_status/supported_states > > > ok 0x0004 [ ] > > > locate 0x0008 [*] > > > fail 0x0010 [ ] > > > rebuild 0x0020 [ ] > > > pfa 0x0040 [ ] > > > hotspare 0x0080 [ ] > > > criticalarray 0x0100 [ ] > > > failedarray 0x0200 [ ] > > > invaliddevice 0x0400 [ ] > > > disabled 0x0800 [ ] > > > -- > > > supported_states = 0x0008 > > > > > > >cat /sys/class/leds/0000:88:00.0::pcie_ssd_status/current_states > > > locate 0x0008 [ ] > > > > As per what Keith already noted, this is a very elaborate output as far > > as sysfs goes - very human-readable, but it would be complex to parse > > should some software would be interested in showing this values in a way > > or another. > > > > I would propose output similar to this one: > > > > $ cat /sys/block/sda/queue/scheduler > > mq-deadline-nodefault [bfq] none > > > > If you prefer to show the end-user a string, rather than a numeric > > value. This approach could support both the supported and current > > states (similarly to how it works for the I/O scheduler), thus there > > would be no need to duplicate the code between the two attributes. > > > > What do you think? > > Some enclosures may support just one blinky state at a time. Other > implementations might have multiple LEDs and colors, so you could, for > example, "locate" something that is also "failed", with both states > visible simultaneously. You could capture the current states with the > "scheduler" type display, but setting new states may be more > complicated. Ah, excellent point. I didn't think about this - the use-case you provided. This would, indeed, be far more complex to deal with when accepting a write. I can see why Stuart did it the way he did currently. Krzysztof
