Date: Wed, 30 Jul 2003 17:08:34 +0100
From: John Bradford <john@grabjohn.com>
Message-Id: <200307301608.h6UG8YQJ000339@81-2-122-30.bradfords.org.uk>
To: john@grabjohn.com, pavel@ucw.cz
Subject: Re: PATCH : LEDs - possibly the most pointless kernel subsystem ever
Cc: linux-kernel@vger.kernel.org, pgw99@doc.ic.ac.uk
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1578
Lines: 40

> > Does anybody have any suggestions for recommended standard uses for
> > parallel port connected LEDs?

> At one point I had 12 LEDs on parport. LEDs were fast enough to be
> drive at interrupt entry/exit.
> They were: 
> Yellow not idle task
> Green interrupt
> " bh
> " pagefault
> Red lowest 4 bits of PID
> Red, low intensity serial i/o
> " network i/o
>
> It actually looked very good. Glow of interrupt led told you
> interrupt load, pid LEDs told you about what kind of load it is
> experiencing (you could tell shell script from make and from
> computation, and if machine hard-died, you at least knew if it was
> interrupt or process context). 

Sounds like exactly what we need.  If we standardise on something like
the above, we could just have a CONFIG_FRONT_PANEL_MONITOR and ask
people to send in the LED status with bug reports.

> But this kind of blinkenlights needed pretty fast LEDs. (At 486 time
> I decided that parport on ISA is fast enough..)

I'll buy some LEDs and build a parallel port connected LED panel
tomorrow...  Do you think the overhead of driving the LEDs would have
too much of a negative effect on system performance?  If so, or if we
want more flexibility, maybe we could work out a design for a PCI
card, which could include more than 12 LEDs - 7-segment numeric
displays of pid, etc.

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/