Re: [nslu2-linux] Re: [nslu2-developers] leds driver
- On 10/1/05, John Bowler <jbowler@...> wrote:
> Here's my own base requirements:I'll add my ideas. We have quite a few led states available for the
ready/status led, so we should come up with a comprehensive scheme for
using it. Where colours are separated with a slash ("/") in the text
below, it means to flash alternating the colour sequence specified
(i.e. "Red/Green/Off" means red, then green, then off, then repeat).
Let's start with the ones we cant' change:
1/ Off - Power is off (led behind power button is also off), or kernel
has crashed in the led off state while flashing something (led behind
power button is still on).
2/ Amber - We are in Redboot and the system is starting up (but the
kernel hasn't started yet). We can't change this one - it's
hard-coded in the bootloader.
3/ Red/Green - We are in Redboot upgrade mode. We can't change this
one - it's hard-coded in the bootloader.
Now lets set some other principles:
4/ Green - Should indicate that we are in normal user mode and all
services are up.
5/ Green/Off - Should be used to indicate CPU status so that you can
visually distinguish an idle system,from a lightly-loaded system from
a heavily-loaded system.
6/ Green/Amber - System is shutting down
Now let's look at what's left:
These should be used to indicate successful progression from kernel
booting to normal user mode, such that the following failure points
can be identified by the user:
a) Kernel failed to run init
- Propose Red/Off
b) Init failed to pivot to the alternate rootfs
- Propose Red/Amber
c) Startup scripts failed to reach completion
- Propose Amber/Off
d) Kernel panic
- Propose Red
This choice of colour sequences takes into account John's requirements
for flashing during boot and unambiguous state changes and a
deterministically different finish state.
So the kernel would set the leds to Red/Off, then change to Red/Amber
at the start of /linuxrc, then change to Amber/Off after the rootfs
has pivoted and the init scripts have started, then change to Green
(and pass over control to the CPU state driver) in S99finish. A
kernel panic would change to Red, and the shutdown process would
change to Green/Amber.
If the 10 states listed above are not enough to identify all useful
states, or if we wanted to provide the user with additional state
choices, then we can also use the next 10 three colour sequences:
This could be extended indefinitely, even to the point of being able
to spell out morse code in tri-colour.
All of these states could be encoded by strings using the characters
"O"ff, "R"ed, "G"reen, "A"mber, such as:
The kernel driver could cycle through the sequence at a fixed rate
until the sequence was changed, or the scheme could be extended with
numbers inserted in the stream to add durations.
As far as the other leds go, I would like to see a claim/release
mechanism on the disk activity leds, so that those of use who only
need one disk activity led, and want to use the other led for
something else (e.g. mail waiting) can do so.
- On 10/1/05, Rod Whitby <list.nslu2-linux@...> wrote:
> As far as the other leds go, I would like to see a claim/release2nd'ed.
> mechanism on the disk activity leds, so that those of use who only
> need one disk activity led, and want to use the other led for
> something else (e.g. mail waiting) can do so.
I have little need of anything other than what's currently provided -
disk leds flashing on access would be an added bonus. Would prefer the
option to keep disk 1 and disk 2 status seperate.