linux-kernel - Re: [PATCH v2] leds: ledtrig-morse: send out morse code

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]

Date:   Wed, 4 Jul 2018 20:19:16 +0200
From:   Pavel Machek <pavel@....cz>
To:     Willy Tarreau <w@....eu>
Cc:     Andreas Klinger <ak@...klinger.de>, jacek.anaszewski@...il.com,
        ben.whitten@...il.com, geert+renesas@...der.be,
        pombredanne@...b.com, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [PATCH v2] leds: ledtrig-morse: send out morse code

Hi!

> On Wed, Jul 04, 2018 at 08:53:05AM +0200, Pavel Machek wrote:
> > As I stated before, I don't think morse encoder belongs in kernel.
> 
> On the opposite, I think that the kernel needs to be a bit more autonomous
> when it comes to reporting its own issues. Being able to report a panic
> when userland cannot be accessed for example is the reason why we've seen
> various features such as blinking keyboard LEDs for this.

Being able to report panics by blinking would be nice... but proposed
patch does NOT do that.

> > LED pattern trigger should be merged, instead.
> 
> Well, just like we have LED and LED triggers in the kernel, I think having
> a generic way to use patterns could be nice and in this case Morse could be
> one such pattern, but if that means it's limited to userland to configure
> it then it sadly voids all of its benefits.

Proposed patch is already limited to configuration from userland... so
it does not have any benefits.

If special "panic blinking" mode is wanted -- I guess that would make
sense.

But

a) trigger may not be right infrastructure for that; triggers need
quite a lot kernel to be working, as they run in separate threads --
panic blinking probably should be mdelay / brightness set / mdelay,
and probably limited to LEDs that can be accessed without sleeping.

b) we may want trigger to be used for something else (Caps lock? HDD
activity?)  when not panicked. Thus, again, trigger is not exactly
suitable. (It might make sense to blink many/all LEDs simultaneously
to make it super obvious to the user).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)