linux-kernel - Re: introduce delayed-leds.h to reduce code duplication

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Jan 2009 16:54:16 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Pavel Machek <pavel@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: introduce delayed-leds.h to reduce code duplication

On Tue, 2009-01-20 at 10:04 -0200, Henrique de Moraes Holschuh wrote:
> I don't like the loss of functionality of the private workqueue.  I kicked
> the thinkpad led handling to a private workqueue in order to never tie up
> the system-wide one with crap spinning around in the ACPI layer, etc.  In
> fact, all thinkpad-acpi deferred work is in the private workqueue for this
> reason.
> 
> This is easy enough to fix, you just need to provide both versions of the
> interface (standard workqueue, and private workqueue).  OTOH, if nowadays
> the system-wide workqueue runs tasks in parallel and there is no risk of a
> task blocking others from completely unrelated subsystems, I can ditch the
> private workqueue.
> 
> Also, if it is going to be generic, I'd suggest the usual "void *data"
> opaque type to carry information for the driver, instead of a "led number".
> 
> I didn't see any comments from Richard, but your comment about a flag seems
> to imply there was a private one?  IMHO enhancing the led class would be the
> best way to go about it, although deferred leds are simple enough that it
> doesn't matter much.

I think the best approach is to get this header working and then see how
many people can really share it. If its common enough we can add to the
core but lets see if its a useful abstraction first?

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre

--
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/