Char device vs. /proc
Currently the LED driver is done using a char-device. This wastes a major
number and is probably not very useful.
Better idea would be to have a /proc entry for it which can then be used to
communicate with the driver. Since I do not know (yet) how to do this this
is planned for one of the next versions.

Integrating functionality
The knight-rider type of visual effect and the procled funtionality could be
integrated into the module and a mode-toggle implemented like
 mode 1 - simple display of what is written to it (that's what led.o does)
 mode 2 - like procled
 mode 3 - like knight-rider
Perhaps I'll do that when I find out how I can evaluate the machine's
load from within kernel-code.

Problems
It my occur that under heavy load of the machine a 0xff is displayed on the
LEDs. I do not know why and this is mostly due to the fact that the LED
interface is mostly undocumented. All knowledge so far is from
diasassembling the SROM code and trial and error. Better ways to do it are
always welcome!

kerneld
For some mysterious reason only root can start a program that uses the
module and have the module inserted automatically. Normal users will get
something like 'no such device'. Any ideas?
