linux-kernel - Re: [PATCH] Add the LED burst trigger

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: <20131227152354.GA24152@amd.pavel.ucw.cz>
Date:	Fri, 27 Dec 2013 16:23:55 +0100
From:	Pavel Machek <pavel@....cz>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Joe Xue <lgxue@...mail.com>,
	"cooloney@...il.com" <cooloney@...il.com>,
	"rpurdie@...ys.net" <rpurdie@...ys.net>,
	"rob@...dley.net" <rob@...dley.net>,
	"milo.kim@...com" <milo.kim@...com>,
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH] Add the LED burst trigger

On Fri 2013-12-27 14:18:26, One Thousand Gnomes wrote:
> > At least nokia N900 actually has "hardware acceleration" for LED
> > blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing
> > complete with something like 20 _bits_ of storage and 30 program
> > steps). Apparently, it makes more stable patterns (timing is very hard
> > to guarantee from userspace) and better power consumption (no need to
> > wake the CPU to blink the LEDs).
> > 
> > Now, wins from going userspace->kernel will not be too huge. But "If
> > the hardware can accelerate it, kernel should offer it even on
> > hardware that can not do it, for consistency".
> 
> Why ? My x86-64 box can run with 8GB processes, perhaps we should emulate
> 64bit on a 32bit kernel for consistency ?

Umm, you know that we can't really emulate 8GB processes. I believe
this is more like TCP; it could be done in userspace library, but it
is probably better in kernel.

But we already have perfectly good LED trigger system, including
"heartbeat" LED.

> It's another waste of resources - pages of memory that would cumulatively
> be vastly more efficiently used by user space. Yes the N800 might
> want a

Well, this one will be really smaller. And yes, it will make some
memory non-swappable, but I believe with triggers and infrastructure
for N900 (and similar) it will be worth it.

Plus, it will actually save CPU cycles, and thus significant power.

Lets see:

0) on N900, zero CPU wakeups.

1) in kernel: hw timer wakes up cpu, it toggles led, goes back to
sleep. (It might be even optimized not to wake the CPU all the way, as
in zaurus charging case)

2) in user space: hw timer wakes the cpu, switch to userland
application, something like 4 syscalls to write to /sys toggling the
LED (== 8 context switches). On otherwise idle arm system, it might be
factor of 2 in power, and well worth optimizing for.

> little driver but the rest belongs in a library and the library can use
> accelerators (of any kind) if available, or even things like lightbulbs
> via X10 so you can have the big red light in the control room flash if
> the machine dies  8)

Well, I'd prefer my cellphone to signal me "you have a message" by
flashing blue light, not by dimming lights in the control room ;-).

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/