lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <468D54F6.9080808@tmr.com>
Date:	Thu, 05 Jul 2007 16:30:46 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Pavel Machek <pavel@....cz>
CC:	Andi Kleen <ak@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Indan Zupancic <indan@....nu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: blink driver power saving

Pavel Machek wrote:

>>> ...drivers are not expected to act on their own. I was expecting to
>>> get nice /sys/class/led* interface to my keyboard leds.
>> What's the benefit of such an interface? If you're able to trigger
>> keyboard LEDs via that interface, you're also able to use the ioctl()
>> on /dev/console.
> 
> Well, at least it is standartized interface... plus it can do stuff
> like "blink that led on disk access".
> 
One of many useful things for system without blinking lights, disk 
network, thermal alert, etc. And a cheap helper for handicapped folks 
who can't hear an audible alert.

>> I think the intention of the blink driver was to have a *early* blink,
>> i.e. before initrd (and on systems without intrd, before the first
>> init script runs).
> 
> ...and yes, it can autoblink, too. It should be even possible to set
> default behaviour of led to blink, doing what the blink driver does,
> but in a clean way.

Endlessly useful, alarm clock, non-fatal errors on boot, etc.

<it would be nice>
If this were done, priority levels would be nice, so the "I'm taking a 
dump" or "panic" would block lower level system use like disk or network 
lights, and user applications would have some policy to put them higher 
or lower than the pseudo disk light (or not).
</not nice>

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ